| | <<<Back 1 day (to 2014/01/06) | 20140107 |
| Robin_Watts | Your ghostpdl.git repo is supposed to be in /home/ray/repos/ | 00:00.16 |
| | but you have no repos directory. | 00:00.37 |
| | so someone has deleted it. | 00:00.46 |
| watson_ | Is it true there are MuPDF devs in here? | 03:05.08 |
| whimsy_sun | Hi gays, i want to convert pdf to html, and i want to know how mupdf to parse the pdf. And i clone the source code , where should i begin to read? | 07:18.41 |
| Aprowler | hi | 09:06.43 |
| ghostbot | hola | 09:06.43 |
| Aprowler | ghostbot are u eggdrop | 09:06.52 |
| | i want to ask small question about mupdf for android application, | 09:09.09 |
| kens | Don't ask to ask, just ask | 09:09.23 |
| Aprowler | we solve video its ok, but the source hasnt got autplay feature how can we add or you will be add? | 09:09.52 |
| kens | Aprowler : I have no idea what you mean. The MuPDF viewers don't support video at all as far as I'm aware | 09:10.22 |
| | So its not clear to me what 'autoplay' should do, if anything | 09:10.45 |
| Aprowler | kens: ok i think our developers added the source and they also solve the autplay function | 09:11.27 |
| | very thanks | 09:11.31 |
| kens | Aprowler, what application is this ? The MuPDF developers may be interested | 09:12.01 |
| Aprowler | application not developed yet we are at reader part; we have ios applications with another reader, we will use mupdf at android side | 09:12.38 |
| | when we have published | 09:12.51 |
| | i will tell here | 09:13.08 |
| kens | Hmm, OK, I think they would still like to know when you are done. | 09:13.08 |
| | THanks | 09:13.11 |
| Aprowler | thanks sincerely | 09:13.40 |
| sebras | Aprowler: are you talking about video files embedded inside PDF documents? | 09:13.42 |
| kens | sebras scared him off :-) | 09:13.57 |
| sebras | :) | 09:14.28 |
| chrisl | Hmm, how odd: "I need to ask how to do what we've already done....." | 09:14.37 |
| kens | It did seem like a peculiar question | 09:14.50 |
| sebras | sounds like a question that a project manager might have... /me has bad experiences from talking with them...\ | 09:15.13 |
| kens | But I see a lot of those. Like the one on SO who couldn't run make, so he installed that, then wondered why there was an error in 'CC@ and finally why 'nano <file>' ddidn't work either.... | 09:15.43 |
| | sebras, yeah it did sound horribly familiar..... | 09:16.03 |
| ray_laptop | good morning, all | 15:06.31 |
| kens | Morning Ray | 15:06.54 |
| henrys | ray_laptop: early for the meeting ;-) | 15:07.00 |
| kens | meeting in 25 minutes ? | 15:07.05 |
| henrys | yup | 15:07.35 |
| kens | Good enough, still time to get a coffee then | 15:07.50 |
| Robin_Watts | 146 new fuzzing crashes inbound from the same source as before. | 15:09.58 |
| ray_laptop | henrys: yeah, since I can't drive the kids to school, so I might as well start work. | 15:10.14 |
| henrys | Robin_Watts: oh was that addressed just to you? | 15:10.58 |
| Robin_Watts | Miles and me. | 15:11.28 |
| henrys | Robin_Watts: can you send it to support | 15:11.47 |
| | ? | 15:11.58 |
| Robin_Watts | In our commercial discussions with that potential customer, they asked about the progress on the fuzzing bugs. | 15:11.59 |
| | (This was a month or so ago - during hawaii, I think) | 15:12.16 |
| | and they just replied saying "we have more. Do you want them?" And I said "Yes please". | 15:12.36 |
| | Will forward to support. | 15:12.40 |
| henrys | Robin_Watts: absolutely amazing one group knows about the other? | 15:12.53 |
| Robin_Watts | I think they were surprised to discover one another :) | 15:13.35 |
| henrys | I'm beginning to wonder if tor8 has the right idea we should take a break and just fix bugs⦠oh maybe we're doing that ;-) | 15:14.26 |
| ray_laptop | looks like the pdf14 optomization needs some more work for "all devices" :-( | 15:15.24 |
| Robin_Watts | henrys: I did a pass through the mupdf bugs between xmas and new year. | 15:16.13 |
| henrys | Robin_Watts: ghostscript only 3, that's good ⦠| 15:16.16 |
| Robin_Watts | I skipped font ones, and android ones and X ones etc. | 15:17.29 |
| | paulgardiner has done several of the android ones too. | 15:17.46 |
| henrys | Robin_Watts: maybe tor8 can look at the rest? | 15:18.01 |
| tor8 | henrys: yup. that's my plan. | 15:18.22 |
| | do some serious triage and hopefully close off a lot as wontfix or later | 15:18.48 |
| Robin_Watts | yeah, a lot of them are 'enhancement' bugs, I think. | 15:19.05 |
| paulgardiner | Ah tor8: there are 5 iOS commits on paul/master - none of them huge. | 15:20.44 |
| henrys | a quote I read in some emacs blog: women use vi hoping it will change and men emacs hoping it will stay the same ⦠both are disappointed. | 15:21.36 |
| | I see kens has been quietly whiddling down gs bugs. | 15:30.20 |
| kens | :-) | 15:30.28 |
| | Doing my best | 15:30.38 |
| kens | wonders if whiddling is a US spelling | 15:30.56 |
| henrys | the big news is artifex has acquired the smart office code and now we figure out what to do with it. | 15:31.37 |
| kens | I followed the chat | 15:31.49 |
| | But I'm not clear on exactly what we have. Maybe this is a staff meeting discussion | 15:32.16 |
| henrys | I think we can agree paulgardiner should look at an "Office" for mupdf, interleaving that with iOS ⦠| 15:32.56 |
| kens | Yes, that at least seems obvious | 15:33.10 |
| henrys | Sorry Office front end | 15:33.10 |
| kens | Since it was the original motivation :-) | 15:33.27 |
| paulgardiner | henrys: yeah, suits me. | 15:33.41 |
| | I'm hoping the iOS work is close to done, at least enough for a new release. | 15:34.14 |
| henrys | I do think the not so obvious things should have a dedicated meeting perhaps a phone conference or something like that. more interactive that irc. | 15:34.17 |
| | s/that/than | 15:34.31 |
| kens | More interactive certainly, and less public also for now | 15:34.38 |
| Robin_Watts | kens: We have basically ended up with everything that picsel ever checked into their cvs tree. | 15:34.39 |
| kens | Robin_Watts : yes, I gathered that, but I don;t have a good idea of what that entails | 15:34.58 |
| henrys | there is a case for a ghostscript front end we have had request for sending say "Word" to the printer. | 15:35.00 |
| Robin_Watts | This gives us the source for their current apps, plus the history so we can make any of their old apps. | 15:35.06 |
| ray_laptop | Having an Office "front end" makes me think that we are getting something in from the back-end of Office ;-) | 15:35.16 |
| | (steaming pile of it) | 15:35.28 |
| Robin_Watts | The picsel stuff is generally arranged as lots of reusable libs, which can be assembled in different ways. | 15:35.40 |
| mvrhel_laptop | ha | 15:35.41 |
| henrys | ray_laptop:we are all hurling chunks but the marketplace is what it is. | 15:35.54 |
| kens | I think its worth discussing for GS. GG has something 'similar' | 15:35.55 |
| Robin_Watts | lots of the libs have interdependencies, as you'd expect. Not always terribly well documented. | 15:36.27 |
| kens | Robin_Watts : I'm in the peculiar position of understanding the detail better than the overall picture :-) Probably I should do some quick research | 15:36.33 |
| kens | heads off to Google | 15:36.58 |
| Robin_Watts | All Picsels code builds using their own build system, known informally as the FBS. | 15:37.13 |
| mvrhel_laptop | what does FBS stand for? | 15:37.35 |
| Robin_Watts | It copes with building on a range of devices, for a VAST range of targets/configurations. | 15:37.39 |
| | Well, the BS stands for Build System. The F I will leave to your imagination. | 15:37.58 |
| kens | guessed that, sounds like the GS 'build system' | 15:38.28 |
| henrys | More generally Robin_Watts will post a git repo to tech and everyone should probably have a "brief" look at things, perhaps build it and run something. Not something to spend a more than a couple hours on. | 15:38.40 |
| kens | The Picsel web site is really slow for me | 15:39.07 |
| Robin_Watts | In particular, to build on windows, you need a very specific version of python (2.4) | 15:39.15 |
| kens | Oh joy.... | 15:39.23 |
| | I'm not sure I ever got Python running on WIndows | 15:39.32 |
| ray_laptop | henrys: If it only takes a couple of hours to get something built, I will be impressed by the FBS :-) | 15:39.43 |
| henrys | The other issue that doesn't require a lot of interaction or debate is we need to establish the quality of this beast. | 15:40.02 |
| Robin_Watts | When we first approached this the idea was to get just enough to extract the office reading code out. | 15:40.08 |
| ray_laptop | kens: Python on Windows is easy -- just download and install | 15:40.14 |
| | I have had problems with IDL,E, however | 15:40.25 |
| Robin_Watts | and we've ended up with WAY more than that. | 15:40.26 |
| henrys | some reviews have not been good but that is common at the app stores. | 15:40.28 |
| Robin_Watts | I suspect we should be a bit careful not to get too sidetracked by all the stuff we got for free, unless we can see easy wins. | 15:41.06 |
| kens | I'd have thought Robin and Paul already have a reasonable idea ? | 15:41.28 |
| | ray_laptop : never worked for me in the past :-( | 15:41.28 |
| kens | is less worried by app reviews than the quality of the code, especially the 'import' stuff | 15:41.47 |
| Robin_Watts | The liquidators have been selling of licenses to the picsel code to various people that were already shipping the apps. | 15:41.48 |
| ray_laptop | kens: I'll get the latest and try it and let you know if I have problems | 15:42.12 |
| Robin_Watts | and a company has been set up to support these people, called bipartate ltd. | 15:42.13 |
| | ray_laptop: No, you need 2.4 | 15:42.22 |
| | I can post a binary. | 15:42.25 |
| henrys | I wonder if there are standards test for office stuff, like quality logic I haven't looked yet. | 15:42.37 |
| ray_laptop | Robin_Watts: I have 3.2.2 | 15:42.56 |
| Robin_Watts | We are exploring the possibility of bipartate doing a rebranded build of the app for us, so we can get it up on the stores. | 15:42.58 |
| tor8 | I think having isolated independent libs would be fab; not so interested in the app side of things as it seems a lot of others are already doing that | 15:43.10 |
| Robin_Watts | ray_laptop: Then the FBS will fail for you. | 15:43.15 |
| | tor8: Indeed. | 15:43.31 |
| henrys | Robin_Watts: I think you can post the git repo and we'll figure out how much time we want to fool with it, we're big kids. | 15:43.35 |
| ray_laptop | Robin_Watts: I'll wait for the binary. No rush. I have plenty to do | 15:43.36 |
| Robin_Watts | henrys: sure. | 15:43.44 |
| tor8 | ray_laptop: python 3.x and python 2.x are *completely* separate languages, largely incompatible | 15:43.57 |
| ray_laptop | Robin_Watts: NM. I see that Python.org has 2.4 still available | 15:44.22 |
| kens | Seems there is a 2.4 binary for Windows here: | 15:44.38 |
| | http://www.python.org/download/releases/2.4/ | 15:44.38 |
| tor8 | henrys: Robin_Watts: then there is the question of open source licensing... | 15:44.58 |
| henrys | kens:your bug about jbig2 encoding - do we ever test that stuff? | 15:45.06 |
| Robin_Watts | I think picsel have always used activepython 2.4 and the windows binary for that has gone, but I have a copy here. | 15:45.11 |
| | tor8: indeed. | 15:45.16 |
| kens | Did I have a JBIG2 bug ? | 15:45.27 |
| ray_laptop | Robin_Watts: do you know which 2.4 ? I see versions from 2.4.1 .. 2.4.6 | 15:45.42 |
| tor8 | I feel that if we're going to take this stuff on and do some serious work with it (other than just sublicense) we really ought to stay open source | 15:45.42 |
| kens | I think the answer is 'no' anyway henrys | 15:45.44 |
| marcosw_ | henrys: I don't believe we test any encoding. | 15:45.46 |
| henrys | tor8:yea I think that needs to wait for an interactive forum | 15:45.49 |
| Robin_Watts | As well as the basic apps/libs etc, we have a whole bunch of their backend tools. | 15:46.05 |
| kens | bacend tools might be most interesting in the long run | 15:46.32 |
| henrys | kens:http://bugs.ghostscript.com/show_bug.cgi?id=694837 | 15:46.35 |
| | marcosw_: ^^^ | 15:46.42 |
| Robin_Watts | If we want to get work done on the Picsel code (more than we can handle in house), there are various people with experience of the code we can contract out to. | 15:46.44 |
| | I'm not suggesting we rush to this, just mentioning it as a possibility. | 15:47.02 |
| henrys | marcosw_, kens so just let the customer test the fix? | 15:47.05 |
| tor8 | frontend stuff is an eternal race in staying up to date with the current UI and platform fads... | 15:47.17 |
| kens | henrys I'm not aware we ever test JBIG2 encoding | 15:47.18 |
| | TBH I don't believe JBIG2 encoding is worth it, unless you know a lot about the ocntent of the fional image, which we never do. | 15:47.35 |
| ray_laptop | Robin_Watts: right. We sort of have to figure out what we want done before hiring people to do stuff ;-) | 15:47.43 |
| henrys | marcosw_: we should have an overnight for jbig2 encoding no? | 15:47.55 |
| kens | henrys : well, the customer's file works for me now.... | 15:47.59 |
| Robin_Watts | ray_laptop: absolutely. | 15:48.15 |
| henrys | kens:you mean with the patch? | 15:48.16 |
| chrisl | We should remove jbig2 encoding - it's practically pointless...... | 15:48.31 |
| kens | henrys I mean with teh code I posted, I'm sure your patch has the same result though. | 15:48.59 |
| | I think only pdfwrite can test JBIG2 encoding anyway, I don't think we have any other devices which can use it | 15:49.42 |
| marcosw_ | henrys: you realize that we possibly wouldn't have found bug 694837 even with testing since it only happened at a specific resolution. | 15:49.42 |
| tor8 | paulgardiner: 1) you've misspelled transparency in the commit message | 15:49.45 |
| | paulgardiner: 2) I'd rather you fix the library to convert to utf-8 than work around it in the ios code, if that's not a huge bother | 15:49.48 |
| ray_laptop | kens: if we did a jibg2 output device, then we could be sort of smart with text because it comes in via copy_mono, so in theory could be used to build a symbol set (like pswrite did) | 15:50.08 |
| henrys | chrisl: I am in strong agreement with chrisl on this. Eliminate an entire class of problems. | 15:50.24 |
| ray_laptop | kens: but I agree that using JBIG2 encoding in PDF is not useful | 15:50.33 |
| chrisl | ray_laptop: we have a jbig2 output device.... "for testing".... | 15:50.45 |
| paulgardiner | tor8: 2) Yeah, but it will take a fair bit longer to fix the lib and this patch at least stops the app crashing until we get to the lib changes | 15:50.46 |
| marcosw_ | kens: what is the default MonoImageFIlter in pdfwrite? | 15:50.47 |
| henrys | I don't know if marcosw_ is going to like chrisl's idea though | 15:51.47 |
| kens | ray_laptop : yes, we *could* do that, but IMO its *much* more trouble than its worth | 15:52.03 |
| | Unless of course a customer wants to pay us to do it | 15:52.03 |
| | marcosw CCITT G4 | 15:52.12 |
| chrisl | henrys: I'm willing to be swayed by a demonstration of what benefit we get from it | 15:52.19 |
| tor8 | paulgardiner: if they're coming from the PDF it should be a "small matter" of just calling the from_pdfdocencoding conversion function :) | 15:52.25 |
| kens | WHich is faster than JBIG2 to encode and decode and practically as efficient (unless you know the content and are clever) | 15:52.26 |
| ray_laptop | kens: agreed | 15:52.29 |
| tor8 | paulgardiner: but feel free to push it as is, it is marked as Temporary in the comments. | 15:53.09 |
| paulgardiner | tor8: but ownership becomes more difficult | 15:53.10 |
| henrys | I do disagree with having the option and then using tiff secretly | 15:53.11 |
| | kens:we need to take out the option also. | 15:53.26 |
| paulgardiner | I mean ownership of the buffer | 15:53.28 |
| | tor8: okay thanks, so all okay? I'll fix the spelling | 15:53.46 |
| kens | We can remove JBIG2 encoding as a possibility, but I suspect that will annoy customers | 15:53.53 |
| tor8 | paulgardiner: yup. | 15:53.54 |
| | paulgardiner: actually, tag the Temproray comment with "FIXME:" in all uppercase so it's easier to grep for | 15:54.24 |
| | it's what I've done elsewhere in the code | 15:54.30 |
| paulgardiner | tor8: okay | 15:54.37 |
| henrys | kens:there wouldn't be an error right? | 15:54.43 |
| ray_laptop | kens: I don't think we need to drop the option, but IMHO we should say that it is slow and doesn't compress better than CCITT so we can say "we told you so" if any customer complains about the speed or file size | 15:55.28 |
| henrys | I do want to finish at the half hour - sorry the smart office business took so much time. | 15:55.29 |
| | Anything else for the meeting? | 15:55.35 |
| kens | henrys we could possibly arrange an error, but ordinarily we would ignore options we don't understand and use the default. | 15:55.44 |
| | No, I'mfine | 15:55.57 |
| henrys | kens:what do you think? | 15:56.12 |
| kens | ray_laptop : We can certainly put something in the documentation | 15:56.18 |
| mvrhel_laptop | Robin_Watts: I should have a patch for you to review later today | 15:56.20 |
| Robin_Watts | mvrhel_laptop: OK. | 15:56.32 |
| kens | henrys I would just leave the option as it is. | 15:56.32 |
| henrys | kens:and not use the encoder? | 15:56.47 |
| kens | It does actually 'work' (modulo bugs) | 15:56.50 |
| | henrys, no just leave it as is. | 15:56.59 |
| ray_laptop | henrys: is it OK if I work on the clist for pdf14 on non-clist devices and defer the 'all devices' pdf14 optimization issues until after ? | 15:57.04 |
| marcosw_ | ray_laptop: I've been looking through the casper backups for your missing repos directory. | 15:57.17 |
| ray_laptop | I'll open a bug for that, of course | 15:57.21 |
| kens | For commercial customers it will work, and we can presume they know what they are doing when they ask for JBIG2 encoding | 15:57.24 |
| henrys | kens:so your patch seems a bit too liberal can you use something like mine. You should probably commit though you did all the work. | 15:57.51 |
| | s/mine/mine? | 15:58.04 |
| kens | henrys mine was just experimental, yours is better. | 15:58.06 |
| ray_laptop | marcosw: all I need is a fresh repo. All I do, for the most part, is push -f | 15:58.07 |
| marcosw_ | it disappeared between 10/31/13 and 11/15/13. I'm checking the auth.log logs to see if there is a sudo command that removed it. | 15:58.11 |
| kens | henrys I'm perfectly happy for you to commit, I can't remember spending much time on the problem | 15:58.25 |
| henrys | kens:will do | 15:58.36 |
| Robin_Watts | marcosw, ray_laptop: Do we know what happened to rays repos dir? | 15:58.49 |
| henrys | ray_laptop:fine by me | 15:58.59 |
| kens | BTW henrys I did throw a JPEG problemyour way, but it might be better to go to Shelly or someone | 15:59.06 |
| chrisl | kens, henrys, marcosw: There is a jbig2dev that (I think) gets built when the luratec jbig2 code is included - that might be better for testing? | 15:59.11 |
| paulgardiner | tor8: Next thing to sort out for iOS is saving after form edits. Not sure how best to do that in iOS. On pressing the backbutton is natural in Android, but ... | 15:59.22 |
| kens | chrisl I would think that's better than pdfwrite when it comes to testing, yes | 15:59.32 |
| henrys | kens:yeah I saw that - the the problem is p1 bountiable is 1000.00, I think that a bit much for that single problem. | 15:59.53 |
| tor8 | paulgardiner: explicit save buttons would be my preference, but that's not the *apple* way of doing it I gather | 15:59.53 |
| henrys | kens:but I'll look at it and either fix it or move it on to shelly | 16:00.40 |
| paulgardiner | tor8: the other problem I have is that there isn't enough room for all the existing buttons on iPod/iPhone in portraite mode | 16:00.51 |
| kens | henrys its bountiable ? O.O I didn't intend that.... | 16:00.53 |
| tor8 | considering how fond macosx 10.8's preview.app is of clobbering my pdf files just because I selected some text... | 16:00.53 |
| | paulgardiner: I'd save whenever you leave edit mode, or get the "going to background" callback? | 16:00.53 |
| henrys | kens: with an explicit dollar arrangement. | 16:00.57 |
| | kens:no not yet | 16:01.08 |
| kens | henrys http://bugs.ghostscript.com/show_bug.cgi?id=694871 I don't see it as bountiable, did I mess up ? | 16:01.23 |
| | Oh right, for Shelly, sorry. | 16:01.27 |
| Robin_Watts | tor8: the problem is that we don't want to save without a "are you sure you want to save?" question, do we? | 16:02.17 |
| tor8 | paulgardiner: popup menu off the "..." button? | 16:02.32 |
| paulgardiner | tor8: yeah maybe | 16:02.47 |
| | maybe the button | 16:02.52 |
| tor8 | Robin_Watts: considering apple doesn't pop up those anymore... when in Rome? | 16:02.54 |
| henrys | marcosw_, chrisl It does seem the luratech encoder needs some testing. If it is severely broken we should disable it. | 16:03.25 |
| tor8 | paulgardiner: and a popup menu would mean we can fit actual text rather than a set of fairly cryptic icons :) | 16:03.29 |
| kens | doubts teh Luratech encoder is badly broken | 16:03.51 |
| marcosw | speaking of mupdf, I realized a short time ago that we don't run regression tests for mupdf when any of the thirdparty libraries charge. | 16:03.52 |
| tor8 | paulgardiner: Robin_Watts: maybe an "apply" or "save" button somewhere that appears when there have been edits? | 16:04.02 |
| chrisl | Oh, good lord, does sjpegc.c really need it's own memory manager? | 16:04.27 |
| Robin_Watts | tor8: That would seem best to me. but still has the problem that if you load a file, enter some form data, and then change app, you might lose data. | 16:04.42 |
| marcosw | henrys: rather than running a weekly test for the encoder perhaps a one time test will be enough. | 16:04.56 |
| paulgardiner | tor8: trouble with saving every time out of edit mode is that would create multiple incremental updates unnecessarily | 16:05.02 |
| tor8 | Robin_Watts: save to a temp file, and remember that somehow? | 16:05.06 |
| chrisl | marcosw: run it manually when we get updates from luratec? | 16:05.29 |
| henrys | marcosw: sounds good with the filter option that enables it, right? | 16:05.31 |
| kens | marcosw a onetime test would be enough for me | 16:05.43 |
| tor8 | but yeah, not ideal either | 16:05.43 |
| marcosw | chrisl: that's what I was thinking. | 16:05.45 |
| Robin_Watts | marcosw: With git submodules, any changes to the thirdparty modules show up as a commit. | 16:05.54 |
| chrisl | Sounds good to me | 16:05.57 |
| paulgardiner | tor8: with a pop up menu, how do we handle the menu hierarchy? At the moment the nav bar has state, which is quite handy for repetative tasks | 16:06.04 |
| Robin_Watts | Does that commit not trigger a test? | 16:06.06 |
| marcosw | Robin_Watts: I don't believe it's working as it should. | 16:06.37 |
| tor8 | paulgardiner: that's a good question. | 16:07.08 |
| henrys | marcosw: I was going to test the patch myself with the "custom" testing but then I discovered it doesn't do pdfwrite. | 16:07.26 |
| tor8 | paulgardiner: but I believe in as flat hierarchies as possible when it comes to UIs | 16:07.30 |
| marcosw | henrys: yeah, the custom testing stuff can't yet deal with the multiple steps. | 16:08.09 |
| tor8 | paulgardiner: is it the screen where you select between the annotation types to create that's overflowing? | 16:08.14 |
| henrys | marcosw: also I need you to plot test files for me attached to guillaume's bug | 16:09.06 |
| marcosw | henrys: I did that but haven't updated the bug yet. The HP plotter matches GhostPCL. | 16:09.36 |
| paulgardiner | tor8: I think that and the root menu overflow. I've yet to try making the buttons less wide. They are far wider than they need be. But I'm not sure if that is something I can control | 16:10.57 |
| chrisl | kens: did you ever resolve the problem of shutting down pdfwrite/ps2write due to an error? | 16:11.12 |
| marcosw | Robin_Watts: eg. Werner Lemberg commited a change to thirdparty/freetype 33 hours ago but I don't see a commit message in the mupdf log for that. | 16:11.30 |
| henrys | marcosw: do you have the software he most recently recommended? I have SPLOT which he recommended last and it prints it incorrectly. | 16:11.31 |
| kens | Hmm I don't recall the problem chrisl | 16:11.32 |
| tor8 | paulgardiner: the root menu could have a popup submenu with the less commonly used commands | 16:11.41 |
| marcosw | henrys: I do not. Getting a copy was on my list of stuff to do but I didn't. | 16:11.59 |
| tor8 | for the annotation types, maybe a choice-box kind of thing would work? | 16:12.03 |
| chrisl | kens: it was for the fuzzing bugs, you were kicking around the idea a couple of staff meetings back | 16:12.51 |
| kens | I'm afraid I forgot it again :-( | 16:13.04 |
| paulgardiner | tor8: yeah, that might be best. A shame to do that for iPad, which works fine with the current scheme, but then I'm not sure I want to support different ways for iPad and iPhone | 16:13.07 |
| henrys | tor8, Robin_Watts: fairly good case for putting priority on the fuzzing issues (incoming) | 16:14.48 |
| chrisl | kens: I just suspect a lot of these fuzzing bugs are because we try to ignore errors in the PDF interp, and/or because pdfwrite always tries to output the target file (so ends up processing broken, unitialised, incomplete data). | 16:14.54 |
| paulgardiner | tor8: back to saving - a pop up asking if you want to save when leaving edit mode would work well for annotations, but not for form filling because the latter requires no special mode | 16:15.18 |
| kens | chrisl I strongly suspect you are correct | 16:15.47 |
| | But PDFSTOPONERROR is probably the only real solution | 16:15.47 |
| Robin_Watts | marcosw: commits to the thirdparty libs don't affect what revision we use | 16:15.49 |
| | We have to do a commit to mupdf to change the revision for the submodule, and it's then that the tests run. | 16:16.24 |
| | i.e. we have to activate new revisions manually. | 16:16.33 |
| chrisl | kens: I don't think PDFSTOPONERROR helps with the pdfwrite end of things, though - the file I'm looking at is a PS file | 16:16.46 |
| tor8 | paulgardiner: I think the best compromise would be to save the edits to a temp file when the app is swapped out. a button to save properly. and when swapping in, check if the temp file is around? | 16:16.47 |
| | do we have undo? | 16:17.12 |
| henrys | chrisl: but would you be happy with the code if the pdf interpreter avoided the issue with an error? None of the problems I've seen would fall into that category. | 16:17.15 |
| tor8 | if not, I think that should work quite well | 16:17.22 |
| kens | chrisl pdfwrite rarely has a problem, unless you tell it to continue after something catastrophic | 16:17.42 |
| paulgardiner | tor8: yeah, but then we either have to stall the app to save or do it in the background, which might interact badly with user interaction. | 16:18.06 |
| Robin_Watts | tor8: If you double click the button on ios you can get a display of all the current running apps, right? | 16:18.24 |
| paulgardiner | tor8: no undo at the moment. | 16:18.27 |
| chrisl | henrys: eh? Once we've identified data is broken, we throw an error, then try to use the data that caused the error - that's wrong! | 16:18.27 |
| Robin_Watts | and you can close/discard those, right? | 16:18.37 |
| paulgardiner | Robin_Watts: yes | 16:18.46 |
| Robin_Watts | (I watched a friend pull up such a display the other day, and she flipped stuff off the top of the page to close specific ones) | 16:19.04 |
| kens | In particular, when pdfwrite says 'something bad happened, stop now' its not really prepared for the PDF interpreter to just carry on regardelss | 16:19.15 |
| Robin_Watts | Can we put a warning up if someone tries to close an unsaved one ? | 16:19.24 |
| paulgardiner | Robin_Watts: that's how it's done in 7.1 | 16:19.25 |
| marcosw | Robin_Watts: right, so that makes git.ghostscript.com kind of confusing for the thirdparty stuff for an uninformed user (me) since we show the entire history. | 16:19.30 |
| paulgardiner | I man flipping up | 16:19.45 |
| Robin_Watts | No, I man flipping up. You paul. | 16:20.15 |
| paulgardiner | :-) | 16:20.33 |
| Robin_Watts | marcosw: possibly, yes. | 16:20.51 |
| | henrys: I don't see the message you were referring to | 16:21.19 |
| henrys | chrisl: I haven't looked at many of them but using the bad data again just seems to discover a place in the code that needs to be more robust anyway. Adobe does not stop nor does HP PCL I don't see how we can just atopy emulating them. | 16:21.26 |
| marcosw | ray_laptop: I've searched the auth.log logs for any sudo commands that affected your repos directory and there were none. It's possible someone did a 'sudo su' and then removed that directory, but there is no way of finding that. | 16:21.37 |
| paulgardiner | Robin_Watts: I think when people use that method to close an app they are trying to avoid any changes it might have made. It's usually what you do to get rid of an app gone rogue | 16:21.41 |
| Robin_Watts | paulgardiner: At the very least, can we put a big "*" on the image of the app or something to indicate that it needs saving ? | 16:22.15 |
| marcosw | is there any point with restoring the last valid repos directory? It's from November. | 16:22.15 |
| chrisl | henrys: both Adobe and HP will stop processing a Postscript file which generates an error - that's how Postscript works. | 16:22.36 |
| ray_laptop | marcosw: No problem. Can you (or Robin_Watts) just make one for me to throw stuff (patches for review) into ? | 16:22.49 |
| Robin_Watts | marcosw: We should restore the old one, then let ray push his current one to it. | 16:22.59 |
| | That way we stand the best chance of not losing any historical old branches that are in there. | 16:23.19 |
| chrisl | kens: in this case, we got an incrementally defined type42, and we get an error in another part of the job, so we do the normal error thing and exit. At which point, pdfwrite tries to copy the partially defined type42..... | 16:23.20 |
| paulgardiner | Robin_Watts: yeah, but I still need to decide how the user provokes a save | 16:23.29 |
| ray_laptop | Robin_Watts: marcosw: I have no need of the old one. It'll just take longer to push to it, I think | 16:23.33 |
| henrys | chrisl: I have no argument with a postscript file erring out. I'm talking about PDF and PCL. | 16:23.53 |
| kens | chrisl that is an unusual case, probably pdfwrite needs to know there is a font problem, so we should tell it somehow. | 16:24.02 |
| | henrys, Adobe don't convert PDF to PDF. | 16:24.19 |
| paulgardiner | One really easy way, that would be similar to Android is to offer to save when the user goes away from a document back to the library. | 16:24.21 |
| Robin_Watts | paulgardiner: Can we have a 'save' icon that only appears in the corner of the screen when there are outstanding changes? | 16:24.34 |
| marcosw | ray_laptop and Robin_Watts: I'll put the old one into /tmp, and then you two can decide what to do with it. | 16:24.35 |
| kens | THe problem with teh PDF interpreter is that if we get an error processing a PDF input file, the PDF interpreter just carries on | 16:24.38 |
| | If the error is thrown by pdfwrite it (not unreasonably) expects the interpreter to stop. If it doesn't but carries on, everything breaks. | 16:25.04 |
| henrys | kens:I though we were talking generically about the fuzzing bugs and not any particular device. | 16:25.04 |
| paulgardiner | Robin_Watts: yeah, I've wondered about that, but on iPhone we already are having trouble fitting our current buttons | 16:25.10 |
| | Robin_Watts: I think that would work well on iPad | 16:25.40 |
| kens | henrys no chrisl was talking about pdfwrite | 16:25.44 |
| chrisl | kens: I don't see how we can tell pdfwrite the font is incomplete without a shed load of extra cr*p - like monitoring dictionary writes and things like that | 16:26.02 |
| henrys | kens:sorry nvm what I said then, | 16:26.32 |
| | Robin_Watts: I just said the fuzzing bugs deserve priority. | 16:26.58 |
| kens | chrisl Offhand nor do i, but if it doesn't know its incomplete, how should we tell it not to emit the PDF file ? Itr needs to know *somehow* that there is an error | 16:27.05 |
| Robin_Watts | henrys: right. I read your comment as being that there was an incoming message that perhaps added more urgency to that. | 16:27.42 |
| | but as soon as we get the new fuzzing files, I'll start on them. | 16:27.57 |
| chrisl | kens: the file throws a /syntaxerror - between the font being created, and all the glyphs being filled in. With a normal rendering device that's not a problem, but with pdfwrite...... | 16:28.25 |
| kens | Right. So there are 2 solutions (or one disguised 2 ways): | 16:29.56 |
| | 1) Whenever we throw an error we need to tell pdfwrite (which is ugly) | 16:29.56 |
| | 2) Whenever we close a device we need to tell it if the device is closed due to an error | 16:29.56 |
| chrisl | Yes, 2) was what you were talking about at the staff meeting | 16:30.25 |
| kens | 1) doesn't sound feasible (especially given that its permissible to ignore errors and continue) | 16:30.37 |
| | OK but I'm not cleaqr on how we could implement that | 16:30.48 |
| chrisl | No, I just hit this bug, and remember talking about it with you, and wondered if you'd got anywhere. | 16:31.32 |
| kens | Presumably nobody would be happy with changing the device API so that the device close() takes a reason parameter (normal exit, device deactiovation, error...) | 16:31.35 |
| Robin_Watts | kens: We could have a new device entrypoint close_with_reason. The default implementation of which would be to call close. | 16:32.25 |
| kens | Robin_Watts : which is yet another change ot the device API :-( | 16:32.42 |
| Robin_Watts | but it's a backwardly compatible one. | 16:32.52 |
| chrisl | kens: what about if we're trying to emit a file with more pages than we've see showpages? | 16:33.05 |
| kens | Yeah, but I hate this slavish obsession with backwards compatibility | 16:33.06 |
| Robin_Watts | I'm not advocating it, just mentioning it as a possibility. I don't understand the problem enough to comment with more accuracy. | 16:33.12 |
| kens | chrisl we permit that in pdfwrite | 16:33.16 |
| Robin_Watts | kens: ooh. | 16:33.32 |
| | We could have a device_special_op. | 16:33.41 |
| kens | Robin_Watts : I was considering that, I'm also looing at setting a flag in the device structure | 16:33.56 |
| chrisl | kens: er, when does pdfwrite see that other than in an error condition? | 16:34.06 |
| kens | chrisl if we get an EPS | 16:34.16 |
| Robin_Watts | Whenever the interpreter hits an error, it can do a gxdso with the error code etc. | 16:34.19 |
| kens | Robin_Watts: no that won't work | 16:34.33 |
| Robin_Watts | kens: why not ? | 16:34.38 |
| chrisl | kens: if we get an eps, Ghostscript automatically appends a showpage at the end of the file..... | 16:34.43 |
| kens | there are errors we can ignore (the PDF interpreter works that way) and there are erros we *must* ignore(remap_color for example) | 16:35.07 |
| chrisl | Robin_Watts: look up "stopped" in the PLRM | 16:35.12 |
| Robin_Watts | kens: OK, sorry, not "whenever it hits an error" then. | 16:35.26 |
| kens | chrisl onl;y if it *knows* its an EPS. there's code specifically to deal with content and no showpage | 16:35.31 |
| Robin_Watts | "whenever it hits an error that would cause it to abort" ? | 16:35.37 |
| kens | Robin_Watts : the problem is in identifying that. | 16:35.59 |
| | I think creating a new flag in the device structure may be easiest | 16:36.16 |
| Robin_Watts | It would require code in the pdf interpreter, right? | 16:36.24 |
| kens | But I would need to look at this quite carefully | 16:36.25 |
| | Robin_Watts : no, the PDF and the PS interpreters | 16:36.35 |
| | Mainly the PS interpreter really | 16:36.41 |
| chrisl | kens: surely the problem with a device flag is the same - how and when to set it? | 16:36.54 |
| Robin_Watts | what chrisl said. | 16:37.04 |
| kens | chrisl yes, agreed. I'm thinking that a flagis just easier though | 16:37.12 |
| Robin_Watts | flag is a change to the device structure, dso isn't. | 16:37.38 |
| kens | SOrry 2 conversations + reading code is too much for my bear like brain | 16:37.42 |
| | Robin_Watts : yes, but a flag doesn't cause nay problems either | 16:37.55 |
| Robin_Watts | what problems does a dso cause? | 16:38.05 |
| kens | None, per se | 16:38.15 |
| Robin_Watts | flags are nastily persistent, possibly? | 16:38.29 |
| kens | But nor does a flag | 16:38.34 |
| chrisl | Robin_Watts: the flag can be in the pdfwrite device structure, rather than the "public" device structure | 16:38.57 |
| kens | I'd only set the flag on exit due to error (assuming I can dientify such) | 16:38.59 |
| marcosw | ray_laptop and Robin_Watts: /tmp/repos is now on casper. The /tmp directory gets wiped on boot, so it will go away at some point (I know you know this but I've been reading too many tailsfromtechsupport of people intentionally storing important files in the Trash (or whatever it's called on Window) and then being surprised when they are gone). | 16:39.13 |
| Robin_Watts | chrisl: how would that flag be set then ? | 16:39.14 |
| chrisl | Robin_Watts: I already asked that ;-) | 16:39.28 |
| kens | Robin_Watts : for pdfwrite I would need to set a flag in the PDF device strujcture, so that on exit (afyter the dso) I could consult it to see why. I see it as simpler just to set the flag | 16:39.35 |
| Robin_Watts | chrisl: Setting a flag in the general device structure or doing a dso is the same problem. | 16:40.00 |
| | Setting a flag in a pdfwrite specific device structure is another layer of complexity. | 16:40.14 |
| kens | Yes, the identification is the same rpoblem, but see above Robin_Watts in response to the DSO any sane device would have to record the event so that, on device close it could interrogate it | 16:40.52 |
| chrisl | Robin_Watts: it will need a flag anyway, so pdf_close() will know whether or not to emit the file. | 16:41.06 |
| Robin_Watts | kens: right. I accept that the pdfwrite thing would have to catch the dso and set it's own private flag. | 16:41.21 |
| kens | It seems simpler to me just to set the flag in the device common structure | 16:41.24 |
| | Robin_Watts : any device which cared would have to do so | 16:41.37 |
| | SO it seems simplest for us just to set it. | 16:41.48 |
| Robin_Watts | kens: except adding flags in the device common structure that are really private to a given device is nasty. | 16:41.50 |
| kens | Robin_Watts : they are not private, they are common to all devices, bt most devices probably don't care | 16:42.09 |
| paulgardiner | Robin_Watts, tor8: we already have the document name in the centre of the nav bar. I could prefix a star to the name when the doc has been altered, and tapping on the name could provoke save. Only trouble, no one will guess that's what you need to do. :-) | 16:42.17 |
| kens | s/they are/it is/ | 16:42.24 |
| chrisl | <sigh> I really didn't mean to spark this discussion....... | 16:42.33 |
| Robin_Watts | It's a pollution of the device common structure for the sake of information private to a given device. | 16:42.37 |
| chrisl | Robin_Watts: really to a class of devices - this is information useful to all high level devices | 16:43.12 |
| kens | Robin_Watts : I disagree completely. THe fact that a device is closed for an error condition is *NOT* specific to pdfwrite. Its true that, to date, only pdfwrite cares, btu that's not the same at all | 16:43.14 |
| Robin_Watts | Ok. If the flag is sufficiently clearly documented, then fair enough. | 16:44.00 |
| kens | For instance the generic device structure already contains 'pad' and 'log2' which relate to buffers and are therefore irrelevant to pdfwrite | 16:44.07 |
| Robin_Watts | God knows we have enough bits in the device interface which aren't clearly documented at all :( | 16:44.15 |
| | touche, mr sharp :) | 16:44.35 |
| kens | But that still leaves the problem of clearly identifying an error exit condition :-( | 16:45.41 |
| | THat will take more thought | 16:45.41 |
| chrisl | This reminds me of: "Arguing with an engineer is a lot like wrestling in the mud with a pig; after a few hours you realise that he's enjoying it." | 16:45.59 |
| kens | I just discovered that UseCIEColor is present in the device common structure. THat means I *can* raise a warning if people use it with pdfwrite, excellent! | 16:46.56 |
| Robin_Watts | ray_laptop: I'm about to copy the old repo in, and update it with the latest commits. | 16:47.05 |
| | OK, ray_laptop. If you push now, it should hopefully not take too long. | 16:49.40 |
| paulgardiner | Robin_Watts, tor8: it looks like apple intend you to save when the app goes into the background without asking. Actually Adobe Reader does that on Android (whereas we ask first). | 16:51.38 |
| Robin_Watts | ok, so that's not so bad then, right? | 16:55.05 |
| paulgardiner | I think so. It would at least be consistent with other iOS apps. And I can also save when the user closes a document by going to the library, perhaps asking in that case, so the user at least has a way to dump changes | 16:58.15 |
| Robin_Watts | That sounds reasonable to me. | 16:58.32 |
| paulgardiner | Good | 16:58.36 |
| ray_laptop | Robin_Watts: Thanks. That wasn't too painful. At least I have a repo now :-) | 16:59.09 |
| Robin_Watts | ray_laptop: You've never had a mupdf one, right? | 17:00.06 |
| | Was a decision reached on a location for the march or june staff meetings yet? | 17:01.37 |
| kens | Not that I've seen | 17:01.54 |
| | Scott suggested Dallas for March, which is fine by me | 17:02.11 |
| | WOUld be interested to see his airstrip | 17:02.26 |
| Robin_Watts | is going to see it in August anyway :) | 17:02.54 |
| | Well, assuming American airlines doesn't mess us around any more. | 17:03.08 |
| kens | You are off the US in August ? | 17:03.24 |
| Robin_Watts | had booked a holiday in Chile/Bolivia back in October. | 17:03.33 |
| | Flying out via Miami, and back via Dallas (so we could stop in a see Scott). | 17:03.51 |
| | American just changed the Miami->La Paz flight. Instead of leaving at 11 at night, it now leaves at 2pm. | 17:04.18 |
| kens | AH I see | 17:04.28 |
| Robin_Watts | which means there are no flights into Miami in time to catch the damn flight. | 17:04.32 |
| kens | Not good | 17:04.37 |
| Robin_Watts | And helen has a concert the night before. | 17:04.38 |
| kens | Oh that's really not good | 17:04.48 |
| Robin_Watts | so we're trying to push the whole trip 1 day further ahead, but we were up against limited availability in hotels etc back in October, so... | 17:05.13 |
| kens | Hmm... :-( | 17:05.37 |
| | brb need to see if we're going ot for pizza or eating in | 17:06.17 |
| | Seems we're going out, so I'll head off now. Goodnight all | 17:07.46 |
| Robin_Watts | night. | 17:08.16 |
| chrisl | night kens | 17:08.25 |
| ray_laptop | Robin_Watts: sorry, was working and didn't see the pop-up. I never had a mupdf repo, no | 17:22.20 |
| | for the logs. I opened bug 694872 for the pdf14 clist optimization regressions with "all devices" | 17:33.30 |
| Robin_Watts | ray_laptop: OK, np. | 17:34.20 |
| | ant, how do I despise thee. Let me count the ways... | 17:34.20 |
| ray_laptop | Robin_Watts: you have ant problems? Is that an acronym or do you mean the insects ? | 17:35.40 |
| Robin_Watts | ant = xml based java build system | 17:40.27 |
| | marcosw_: I am downloading a 397Meg zip file of new fuzzes now. | 18:19.50 |
| | Should I add that to the relavent place in tests_private and commit it ? | 18:20.03 |
| marcosw_ | Robin_Watts: sure. I'll run them and open new bugs. | 18:21.38 |
| Robin_Watts | marcosw: Hmm. These are in a different format than before. | 18:25.19 |
| ray_laptop | Robin_Watts: the whole thing ??? | 18:25.21 |
| | that'll sure keep me from ever pulling in the whole tests_private tree :-/ | 18:25.46 |
| Robin_Watts | ray_laptop: how else would I do it ? | 18:25.51 |
| | tests_private is 25Gig or something already. | 18:26.06 |
| ray_laptop | Robin_Watts: Yeah, I know :-( | 18:26.18 |
| | Robin_Watts: but other than Marcos pre-scanning for duplicate issues (bad filter data, etc.) I guess we might as well have them all. | 18:27.16 |
| Robin_Watts | Within the zipfile, I have lots of 32 character hex string named directories (presuambly hashes of some kind) | 18:27.38 |
| | In each of those directories I have a few files signal_sigsegv_86190e_5450_4663.pdf etc | 18:28.34 |
| henrys | I wonder if sshfs would be too slow for testing purposes, then we could all just mount this uber test directory | 18:31.04 |
| Robin_Watts | marcosw: I'm going to check that in into tests_private/fuzzing/mupdf2, so we'll have lots of directories in mupdf2, each with a few files in. Will that cause your scripts any problems ? | 18:31.39 |
| | henrys: I suspect that would result in massive bandwidth builds as each cluster node would then end up redownloading stuff repeatedly, right? | 18:32.20 |
| | There is no way to predict what node will need what files. | 18:32.31 |
| | It's worth pointing out that if you want a single file, you can get it from the regression dashboard without needing to download the whole of tests_private. | 18:33.26 |
| henrys | Robin_Watts: the cluster do what they do now. I'm talking about exporting to us. I assume the nodes are able to handle the tests but ray_laptop or I are not. | 18:33.42 |
| marcosw_ | Robin_Watts: I'll have to adapt the fuzzing test scripts but it's not a big deal. Are the filenames not unique across directories or is there sums other reason to preserve the directory names. | 18:33.50 |
| Robin_Watts | marcosw_: I am not aware of any conflicts, but I haven't looked. | 18:34.14 |
| | would you rather I flattened them ? | 18:34.22 |
| | There are a few files that conflict. | 18:36.10 |
| | I could rename all the files from being directory/name.pdf to be directory_name.pdf ? | 18:36.29 |
| | That would result in long names, but they would be unique and wouldn't require changes to the scripts. | 18:36.57 |
| marcosw_ | Robin_Watts: either is fine. I guess keeping in the current directory structure make as much sense as anything. | 18:41.14 |
| | the test code will end up using directory__name.log as the output name in any case. | 18:41.46 |
| Robin_Watts | marcosw_: I'm attempting the rename now. | 18:42.12 |
| | let's not make work for ourselves in changing the cluster scripts unnecessarily :) | 18:42.30 |
| marcosw_ | I should probably re-run the original fuzzing test files at some point as well, to make sure we haven't reintroduced any issues. | 18:46.44 |
| | Robin_Watts: I did run a mupdf fuzzing of our normal test files last month and the only issues I found are a couple of "memory exceeded" problems. Do you think it's worth opening bugs for these? | 19:02.23 |
| Robin_Watts | for memory exceeded? no. | 19:03.38 |
| marcosw_ | marcosw: I didn't think so. | 19:36.31 |
| Robin_Watts | Talking to yourself again, eh? It's the only way you'll get any intelligent responses around here. | 19:37.02 |
| | tor8: So, we may have discussed this before, but... | 19:54.49 |
| | If someone gets a const fz_colorspace * passed to them in (say) a device entrypoint, and they want to take a reference to it, they call fz_keep_colorspace | 19:55.55 |
| | and that gives a warning about casting away a const. | 19:56.02 |
| | I kinda feel we should offer fz_keep_const_colorspace as well as fz_keep_colorspace for this reason. | 19:56.22 |
| | We'd have to cast away the const internally to the implementation of fz_keep_const_colorspace, but at least that's only 1 warning within the lib, rather than 1 warning whereever we need to do that. | 19:57.02 |
| marcosw | chrisl_away: for the logs. your are correct in recalling that the luratech build of ghostscript includes a jbig2 device. Any suggestions how to convert these files into something useful, like pbm? | 20:14.25 |
| | chrisl_away: and no, jbig2dec doesn't do it, it reports: jbig2dec FATAL ERROR Not a JBIG2 file header | 20:19.54 |
| mvrhel_laptop | bbiaw | 20:33.44 |
| tor8 | Robin_Watts: why are we passing const colorspaces? | 20:35.56 |
| | that doesn't sound quite right | 20:36.01 |
| Robin_Watts | When we make a device call to say draw a path. | 20:36.21 |
| | We pass in a color and a colorspace. | 20:36.29 |
| | The colorspace is const, because we don't people to fiddle with it. | 20:36.51 |
| tor8 | maybe I slapped on const a bit too eagerly there | 20:36.51 |
| Robin_Watts | Same thing with shades and images etc. | 20:37.01 |
| | and paths. | 20:37.06 |
| tor8 | refcounted stuff shouldn't (obviously) be const | 20:37.08 |
| Robin_Watts | being called for food, sorry. | 20:37.27 |
| tor8 | Robin_Watts: um. fz_colorspace isn't const in the device interface... | 20:37.42 |
| Robin_Watts | Hmm. Maybe it's just me in the jni stuff then. I will check later. Sorry! | 20:38.21 |
| tor8 | I think it must be, I can't find any "const fz_colorspace" anywhere in the source using recursive grep | 20:38.53 |
| henrys | wow anybody here about cairo becoming part of ISO c++? | 20:45.18 |
| tor8 | henrys: yeah. like that's ever going to happen... | 20:45.53 |
| | it's extra funny because they want to preprocess the source to c++-ify it first... | 20:46.18 |
| henrys | tor8:I don | 20:47.52 |
| | t't understand why it would even be considered | 20:48.02 |
| | I mean why any 2d graphics library would be included in the standerd | 20:49.09 |
| tor8 | I think they've run out of other things they can bloat c++ with :) | 20:50.36 |
| yecril71pl | I can render a document using gs but it fails in libspectre. | 22:03.37 |
| | I get messages like | 22:04.17 |
| | okular(9401)/okular (Spectre) GSRendererThread::run: Generated image does not match wanted size: [0x0] vs requested [1013x1433] | 22:04.20 |
| | libspectre uses libgs internally | 22:04.41 |
| | Is that to be expected? | 22:04.51 |
| | Note that the document refers to Times | 22:05.06 |
| | and does not contain it | 22:05.13 |
| saper | the message says something about size of some image | 22:05.30 |
| yecril71pl | so gs notifies of font substitution | 22:05.40 |
| saper | there is no output at all? | 22:06.01 |
| yecril71pl | the pages are bloank | 22:06.10 |
| | the pages are blank | 22:06.14 |
| | Does gs use libgs, or the other way round? | 22:07.51 |
| | Forward 1 day (to 2014/01/08)>>> | |
IRC Logs