| | <<<Back 1 day (to 2012/06/10) | 2012/06/11 |
| chrisl | nlogax: the glyphshow operator might allow you to do what you need, but maybe not in the manner you're thinking........ | 07:23.03 |
| kens | You can't add it to a string though.... | 07:40.02 |
| | Better to re-encode the font | 07:40.11 |
| chrisl | That's why I mentioned "not in the manner.." | 07:42.02 |
| nlogax | chrisl: Thanks! I found that eventually, and added an operator for getting the width of a glyph, and some extensions to gonzo. Now I can use unusual characters without that much pain. Only remaining problem is that words might break wherever I use it. :) | 08:45.18 |
| | (Break as in rest of the word moving to the next line) | 08:45.51 |
| | Is there a noob-friendly guide to re-encoding fonts? | 08:46.36 |
| kens | I'm fairly sure there's an example i teh PLRM | 08:46.51 |
| kens | goes to look | 08:47.12 |
| | Hmm, seems not | 08:47.58 |
| | Maybe hte blue book then | 08:48.06 |
| nlogax | Ah, yes, there is an example there. Thanks :) | 08:49.01 |
| kens | NP | 08:49.06 |
| nlogax | Have been searching around, but often using the wrong terminology | 08:49.31 |
| chrisl | Robin_Watts: ping | 09:53.45 |
| Robin_Watts | pong | 10:04.52 |
| chrisl | The cluster's bmpcmp build doesn't like the new libpng (nor the pending zlib update). The libpng problem is because it now has a dynamically created config header file | 10:05.52 |
| Robin_Watts | ah. | 10:07.05 |
| chrisl | So, I was thinking, at least temporarily, I'd update the cluster code to copy the predefined header, build bmpcmp, and delete the header again | 10:07.42 |
| Robin_Watts | sounds good to me. | 10:08.09 |
| chrisl | What I don't know is where to change it (I assume I have to change it in cluster.git), and how to test the change? | 10:08.51 |
| Robin_Watts | just a tick. | 10:09.04 |
| chrisl | I mean I know the file and the lines to edit, but I don't know if the cluster gets run.pl from the cluster's git repos, or the ghostpdl one | 10:10.06 |
| Robin_Watts | Right. The line that builds bmpcmp.c is in run.pl. It's run on the remote machines. | 10:10.27 |
| | and $baseDirectory is the ghostpdl checkout I believe. | 10:10.54 |
| chrisl | Yeh, I know what changes to make - but where to commit and how to test are different matters...... | 10:12.06 |
| Robin_Watts | Easiest thing to do would be to check a version of libpng.h into the main gs repo (libpng.h.gen or something) | 10:13.52 |
| chrisl | I really want to try to minimise how much we faff about with third party library code when we import them | 10:14.49 |
| | Robin_Watts: sorry I misread your comment: There already is a predefined version of the header file, which we use for the GS build - but we copy it during the build to the build directory. | 10:20.35 |
| | So all we need the cluster to do for bmpcmp is the same as the ghostpdl builds do already. | 10:21.38 |
| Robin_Watts | Right... so can you just add lines to run.pl to copy the file from $baseDirectory/ghostpdl/gs/libpng/libpng.h.gen to . ? | 10:23.10 |
| | and then add -I. to the bmpcmp build command ? | 10:23.38 |
| | (actually, better make that ./libpng.h) | 10:24.00 |
| chrisl | Yes, but which run.pl do I edit? And is there a way to test it without committing the change to the repos? | 10:24.15 |
| | Oh, that's weird - run.pl and a few other cluster files exist in one of my ghostpdl checkouts, and not in the other - I wonder how that happened....... so that takes care of *which* to edit! | 10:28.13 |
| Robin_Watts | chrisl: You edit the main one in ~regression/cluster on casper. | 10:31.27 |
| | It's sent around as part of the job setup. | 10:31.34 |
| | The git repo is just for us to keep track of our changes to the cluster code. | 10:31.57 |
| chrisl | Uh, okay, thanks..... I'll do it now | 10:32.15 |
| Robin_Watts | Random question: Anyone on here ever used a 3d printing service? | 10:32.50 |
| kens | Nope | 10:33.05 |
| chrisl | Me neither - I know there isn't one near here, yet...... | 10:33.30 |
| Robin_Watts | There is one in Oxford, but I was considering upload to web/get in post options. | 10:34.02 |
| chrisl | I didn't look into those. I wanted one I could go to and have a nose around | 10:35.43 |
| Robin_Watts | tor8: ping | 12:10.45 |
| d3c | Robin_Watts: someone posted a fix for http://bugs.ghostscript.com/show_bug.cgi?id=693099 but I don't know if that fixes it. | 12:20.33 |
| Robin_Watts | d3c: I have a fix here. | 12:42.02 |
| | But it's part of a more general thing that I want to run past tor. | 12:42.20 |
| | Let me send him a text. | 12:42.28 |
| | he's on a train. will be here in a bit. | 12:46.48 |
| d3c | Robin_Watts: sounding good. I'll run over all the PDFs again ASAP when you push a fix :) | 12:49.55 |
| mvrhel_laptop | hi kens | 13:02.58 |
| | did you see the email that I sent (and cc'd you on) to Avadhut? | 13:03.14 |
| kens | Yes mvrhel_laptop | 13:03.25 |
| | But its not really my bug I think. | 13:03.34 |
| | Let me dig it out and reread | 13:03.40 |
| mvrhel_laptop | Oh. I thought you could answer his questions about the pdfwrite server mode | 13:04.00 |
| | and about font | 13:04.03 |
| | s | 13:04.05 |
| kens | There aren't any real questions that I can answer there | 13:04.11 |
| mvrhel_laptop | oh | 13:04.24 |
| kens | He's already been told that PS->PDF will work | 13:04.34 |
| mvrhel_laptop | yes that one I could handle :) | 13:04.51 |
| kens | Babbling about pipes simply betrays his lack of information | 13:04.56 |
| mvrhel_laptop | hehe | 13:05.17 |
| kens | I have no idea about SUBSTFONT but it sounds like its specifically PostScript to me | 13:05.25 |
| | If he thinks it doesn't work on teh command line then he hsould raise a bug | 13:05.51 |
| mvrhel_laptop | yes. OK. Let me follow up with him to open bugs on this stuff if he has a problem | 13:06.09 |
| kens | I don't understand at all when he talks about 'loading fonts dynamically' | 13:06.24 |
| | We always load fonts dynamically | 13:06.37 |
| mvrhel_laptop | yes. I had no idea | 13:06.39 |
| Robin_Watts | I skimmed one of his mails, and I thought that was to do with the target printer. | 13:07.03 |
| d3c | Robin_Watts: at your latest commit in MuPDF, MuPDF seems to skip some pages when generating PDF -> PNG. did you see this before or should I dig deeper into it? | 13:07.18 |
| kens | He's talking about 'Unicode documents' which doesn't m,ake any sense | 13:07.23 |
| mvrhel_laptop | ok. I don't want to waste anyones time on this | 13:07.54 |
| | I will tell him to open bugs for any issues he has (including enhancement requests) | 13:08.13 |
| Robin_Watts | I suspect he's just failed to understand that the fonts will be pickled into the PDF, so he doesn't need to send fonts to the printer 'in advance'. | 13:08.16 |
| | d3c: No, I don't know about that. | 13:08.29 |
| d3c | Robin_Watts: ok, will see if I can reproduce | 13:08.38 |
| kens | He's talking about PostScript a lot | 13:08.39 |
| Robin_Watts | If you can isolate some examples, I'd love to see bugs please. | 13:08.43 |
| kens | So I assumed he thought the PostScript was in Unicode, whcih is possible but gighly unlikely | 13:09.00 |
| mvrhel_laptop | I am going to start checking my spam mail less frequentyl.... | 13:09.10 |
| kens | And teh only real way to terll would be to run the file through a PostScript itnerpreter.... | 13:09.17 |
| mvrhel_laptop | which is where I found this | 13:09.19 |
| kens | mvrhel_laptop : I would have left it there | 13:09.29 |
| mvrhel_laptop | hehe | 13:09.33 |
| kens | I am supposed to be doing support with Henry so I suppose I can answer if you like | 13:09.52 |
| d3c | Robin_Watts: that was for me? | 13:11.13 |
| mvrhel_laptop | kens: no I took care of it | 13:11.19 |
| | sorry that I dragged you in to this | 13:11.27 |
| kens | OK, thanks Michael | 13:11.31 |
| Robin_Watts | d3c: about examples/bugs? Yes, sorry. | 13:11.32 |
| mvrhel_laptop | kens: I just saw fonts in his email and assumed it made some sense to someone. | 13:11.57 |
| kens | Not to me :-) | 13:12.07 |
| | And I suspect, not to him.... | 13:12.13 |
| mvrhel_laptop | but after dealing with him and color I should have known better | 13:12.14 |
| d3c | Robin_Watts: ok but sure, I think I've got one where MuPDF won't output the right number of pages (it will skip some) and another where it will segfault (even though I'm using your latest commit). I have some results in a few | 13:12.31 |
| Robin_Watts | Separate bugs for both of those would be much appreciated. thanks. | 13:13.41 |
| mvrhel_laptop | ok. plane loading. I will hopefully get some stuff done on this copy alpha fix | 13:15.38 |
| | ttyl | 13:15.51 |
| kens | OK have a good show mvrhel_laptop | 13:15.54 |
| mvrhel_laptop | thanks | 13:15.57 |
| d3c | Robin_Watts: is something like this expected? `warning: font size too large (1032.11), not rendering glyph` | 13:20.24 |
| Robin_Watts | Yes. | 13:20.43 |
| | Look in fitz/draw_glyph.c at the top. | 13:21.17 |
| d3c | ok | 13:21.17 |
| Robin_Watts | #define MAX_FONT_SIZE 1000 | 13:21.30 |
| | change the 1000 to a larger number if you want to avoid that. | 13:21.41 |
| d3c | Robin_Watts: right. why a max size of 1000, though? | 13:21.52 |
| Robin_Watts | tor picked that number years ago. | 13:22.07 |
| | Presumably as a reasonable limit to stop the heap exploding with malicious pdf files. | 13:22.21 |
| | If you've got a reasonable amount of memory, you can probably increase it. | 13:22.41 |
| d3c | Robin_Watts: maybe the limit should be larger by default? this PDF is from an ad agency. maybe their software will use sizes > 1000 when drawing text. | 13:26.16 |
| Robin_Watts | d3c: Possibly it should be increased. But it depends on the resolution you use etc. | 13:26.45 |
| d3c | Robin_Watts: couldn't you look at the memory available and set the limit based on that? or is that hacky? (I don't know anything about C, sorry) | 13:27.49 |
| Robin_Watts | There is no way to portably know what the memory available is. | 13:28.10 |
| chrisl | Shouldn't there be a fallback when a glyph is so big? | 13:29.15 |
| Robin_Watts | chrisl: Maybe | 13:30.16 |
| | Well, we only render via freetype. | 13:30.34 |
| chrisl | You could get the outline from freetype and render it as a mupdf path | 13:30.46 |
| Robin_Watts | right, but that's a whole new codepath we don't have. | 13:31.05 |
| chrisl | I suppose we could just document it as a limitation...... | 13:32.07 |
| Robin_Watts | hey tor. | 14:11.42 |
| tor8 | hi robin | 14:11.58 |
| Robin_Watts | I've been looking into bug 693099. | 14:12.17 |
| | At the moment, if we throw an error from the interpretation or rendering phase, we bale out. | 14:12.50 |
| | (or bail out, depending) | 14:13.06 |
| | I've added 2 new entries to the cookie, errors, and error_max. | 14:13.29 |
| tor8 | is it an inline image? | 14:13.40 |
| Robin_Watts | No, it's an xobject one. | 14:13.50 |
| | (yes, the pdf interpret code has a special case for coping with broken xobject images, but the error isn't thrown until decode in this case, which is in the displaylist playback) | 14:14.32 |
| | I now have some fz_try/fz_catch wrappers in both the displaylist and the interpretation code. | 14:15.24 |
| | If they catch an error, they incremement the cookie->errors count. | 14:15.43 |
| | if cookie->errors < cookie->error_max (or cookie->error_max < 0) then it swallows the error, otherwise it rethrows it. | 14:16.15 |
| | So the caller can now tell it to 'ignore all errors' (or 'ignore the first n errors') and at the end of rendering it can know how many errors got ignored. | 14:17.08 |
| | Does that sound reasonable to you? | 14:17.17 |
| tor8 | probably overkill; but getting an error count could be useful to bludgeon complaining customers with :) | 14:17.52 |
| Robin_Watts | Probably that means I should turn the fz_warns in pdf_run_keyword to be fz_throw's. | 14:27.02 |
| tkamppeter | Is zedonet.com (TurboPrint) licensing Ghostscript? They ship version 8.64 in their package and use it as PostScript and PDF interpreter with all the ooooold bugs. | 14:32.53 |
| kens | tkamppeter they are not a commercial cusotmer as far as I can tell | 14:36.32 |
| | Its possible they use GS in a GPL-complian fashion | 14:37.24 |
| | Given they are on Linux | 14:37.37 |
| henrys | kens:I think at this point you should report your valiant efforts to the customer and tell them they need to upgrade. Even if we could put together something I don't think anyone would be too confident a problem wasn't introduced. | 14:37.48 |
| Robin_Watts | The only mention they make to ghostscript in their manual says: If fonts are not printed | 14:37.54 |
| | correctly, there is a problem with the application and/or the Linux postscript | 14:37.56 |
| | interpreter âGhostscriptâ. | 14:37.58 |
| kens | henrys I've been looking further and I think the new problem is transparency related, not shadings | 14:38.15 |
| | SO I would not feel comfortable ending them a patch even if I could identify one. | 14:38.28 |
| | I will write them a polite email | 14:38.58 |
| Robin_Watts | kens: I suspect they are running close to the wind. | 14:40.03 |
| | We'd need a linux user to install it and see. Certainly they don't look to acknowlege the fact that they install a GPL piece of software on the machine as part of their installation. | 14:41.09 |
| | They do offer a 30 day trial though, so we could try it. | 14:41.31 |
| kens | Sorry Robin_Watts was thinking of the customer bug ;-) | 14:41.34 |
| | Well I could install on my VM or anyone else coul dtoo | 14:41.51 |
| tkamppeter | Are you now talking about TurboPrint or something else? | 14:42.02 |
| Robin_Watts | tkamppeter: turboprint, yes. | 14:42.13 |
| kens | sorry tkamppeter back to TurboPrint | 14:42.16 |
| Robin_Watts | I'll give it a go if people want. | 14:42.19 |
| kens | Sounds good to me :) | 14:42.28 |
| | I tought chrisl might be able to poke it harder was all | 14:42.47 |
| chrisl | Robin_Watts, kens: I'd just refer it to Scott - whether they are strictly legal, or not, it's worth approaching them, I'd say | 14:42.54 |
| kens | Certianly harder than me | 14:42.56 |
| tkamppeter | TurboPrint has a trial, as far as I know it prints a log on the printouts and if you buy a license key you get printouts with logos. | 14:42.58 |
| Robin_Watts | Yes, I was hoping chrisl would jump in and volunteer :) | 14:43.08 |
| tkamppeter | The trial is good enough to explore the workflow. | 14:43.30 |
| Robin_Watts | chrisl: Yes, it's worth reporting to scott, but any additional information we can give scott would be good; he's not going to be capable of doing the tests himself obviously. | 14:43.58 |
| chrisl | Okay, I'll download the trial version, and have a poke at it - probably tomorrow, though - I want to use a VM for the test, and not faff up my "real" machine | 14:45.02 |
| tkamppeter | The point to complain about which I have found is that they ship GS 8.64 (as /usr/bin/gszedo) with a "zedo" output device which produces PPM image files. This old version they use also as a PDF interpreter for the PDF-based Debian and Ubuntu distros and you know how many PDF problems I have reported to you and you have fixed them on the way to 9.05. | 14:46.13 |
| Robin_Watts | tkamppeter: Do they offer source for the zedo device? | 14:46.43 |
| | If not, that's a clear GPL violation. | 14:46.55 |
| tkamppeter | Robin_Watts, I did not find the source yet. | 14:47.11 |
| | Robin_Watts, source code to fulfill licenses is at ftp://ftp.zedonet.com/ but I did not find the GS source code there yet. | 15:00.30 |
| chrisl | I don't see any source there at all...... | 15:03.28 |
| Robin_Watts | tor8: Code review time; I've pushed the fix for 693099 onto my repo on casper for your delight and delectation. | 15:04.42 |
| | d3c: While I wait for tor8 to look over that fix, do you have a file that causes a segv to hand? | 15:06.36 |
| d3c | Robin_Watts: yes, I was actually about to submit it but got on to some other tasks. | 15:06.56 |
| | Robin_Watts: do you want it as a bug report or should I just tell you here? | 15:07.04 |
| Robin_Watts | If you can tell me here, I can open the bug report. | 15:07.23 |
| d3c | Robin_Watts: I'll just do that for you. sec | 15:08.14 |
| | Robin_Watts: http://bugs.ghostscript.com/show_bug.cgi?id=693102 | 15:09.49 |
| | Robin_Watts: got another one I'll submit in a second | 15:09.55 |
| Robin_Watts | Thanks. | 15:09.57 |
| d3c | Robin_Watts: http://bugs.ghostscript.com/show_bug.cgi?id=693103 | 15:17.06 |
| Robin_Watts | I can't reproduce the SEGV locally. | 15:17.23 |
| henrys | alexcher:693101 should go to scott for a possible support contract. | 15:17.31 |
| Robin_Watts | d3c: I see: | 15:18.18 |
| | $ win32/Release/mudraw.exe -o out-%d.png -r2166x831 ../MyTests/3680.pdf 7 | 15:18.30 |
| | error: malloc of array (16715 x 156908 bytes) failed | 15:18.32 |
| | error: cannot draw '../MyTests/3680.pdf' | 15:18.34 |
| | What OS are you on? 32 or 64bit linux ? | 15:19.01 |
| d3c | Robin_Watts: 64bit Linux | 15:19.08 |
| | Robin_Watts: I've got two more of those segfaults but I'm guessing it's the same bug (or whatever it is) | 15:19.26 |
| kens | OMG someone complaining that GS won't process files with > 64k ages.... | 15:20.47 |
| Robin_Watts | kens: It's an extreme case, but not entirely unreasonable | 15:21.14 |
| kens | thinks this is undoubrtedly an atuomated process such as billing and could therfore be done as multiple smaller PDFs | 15:21.58 |
| | Anyway, since the PDF interpreter handles this in PostScript, and we have a limit of 64k entries on arrays, its going to be a problem to fix. | 15:22.38 |
| | Robin_Watts : have you seen the latest one from Gemma Woods ? | 15:24.15 |
| Robin_Watts | kens: Will the next release have the fix in? | 15:24.30 |
| kens | Do we have a proposed solution other than 'that's the way its going to be' | 15:24.30 |
| | That's the question | 15:24.43 |
| | Is there a 'fix' ? | 15:24.57 |
| d3c | Robin_Watts: I actually got 6 more PDFs that will seg fault at certain pages. do you wanna see those or do you think it's the same bug (if it's a bug at all)? | 15:24.57 |
| Robin_Watts | The answer is "Michael is working on it now. We hope to have a fix within a couple of weeks, but this is dependent on many different factors, so don't hold us to that time estimate. We will keep you appraised. | 15:25.34 |
| kens | OK, thanks Robin_Watts | 15:25.45 |
| Robin_Watts | d3c: Yes, we'd like to see them. | 15:26.26 |
| alexcher | henrys: we can support more than 64K pages. The sample file just lists all pages in a single array instead of the usual page tree. | 15:26.33 |
| Robin_Watts | if you wouldn't mind. | 15:26.35 |
| | d3c: OK, on 64bit linux I can reproduce the segv. | 15:27.51 |
| chrisl | alexcher: I thought we were going to remove the 64k limit on strings and arrays? | 15:28.13 |
| alexcher | chrisl: Yes, we should but Ghostscript requires the reference size to be a power of to. | 15:31.12 |
| | chrisl: Yes, we should but Ghostscript requires the reference size to be a power of 2. | 15:31.23 |
| d3c | Robin_Watts: do you want separate bug reports or just attach them to one of the reports? | 15:32.05 |
| Robin_Watts | d3c: ideally, separate bug reports please. | 15:32.23 |
| d3c | Robin_Watts: ok, 5 mins | 15:32.50 |
| Robin_Watts | Although, if they are all crash in exactly the same way (with the same command line) then feel free to stick them all on one, and I'll separate them out. | 15:33.00 |
| alexcher | chrisl: Doubling the reference size wastes memory. Other reference sizes don't work yet. | 15:33.17 |
| chrisl | alexcher: I just wonder if doubling the reference size wastes that much memory when you consider all the code we've got to workaround the limitation........ | 15:34.57 |
| alexcher | chrisl: Not so long ago we were counting megabytes mo meet the embedded device constrains. | 15:38.10 |
| tor8 | Robin_Watts: I would change so that the default (if no cookie) is to ignore all errors. I don't really see the need for error_max. | 15:39.52 |
| chrisl | alexcher: I was serious when said "I wonder" - I don't have a good feel for how much code, and working memory gets used in the workarounds for the limit. Also, there's performance, which is also important to embedded customers. | 15:40.15 |
| Robin_Watts | So... how do you say: "Ignore all errors, but tell me how many you ignored"? | 15:40.22 |
| tor8 | by giving a cookie and reading out the error count. if no cookie, no error count. | 15:40.51 |
| Robin_Watts | So you don't ever see it being worthwhile being able to say "give up after 100 errors" ? | 15:41.28 |
| tor8 | I see someone may want to 'give up if you hit any error' but not an arbitrary number | 15:42.01 |
| Robin_Watts | I guess it depends how long we take to respond to each error. | 15:42.02 |
| | Ok, so how do we say "give up after you hit any error" in your scheme ? | 15:42.21 |
| tor8 | I wouldn't :) | 15:42.56 |
| | but I can (remotely) see someone may want that, but I don't think anyone in practice will | 15:43.17 |
| Robin_Watts | I think we need to be able to offer the "give up after the first error" and "ignore all errors" options. | 15:43.31 |
| | And we ought to offer the "how many errors were there". | 15:43.42 |
| tkamppeter | chrisl, Robin_Watts, if you look into /usr/share/turboprint/doc/license-addons.txt of an installed TurboPrint you see links to source code tarballs, but Ghostscript is not mentioned. | 15:43.56 |
| Robin_Watts | Given those requirements, I can't see a less invasive way of doing it than by what I've done. | 15:44.02 |
| tor8 | I think we should be careful about tacking on a lot of features we have to keep maintaining | 15:44.16 |
| Robin_Watts | tkamppeter: OK, that sounds like a clear violation to me. | 15:44.26 |
| kens | tkamppter; curous, how do you know thaat TurboPrint uses Ghostscript ? | 15:44.27 |
| tor8 | also, I dislike how you now have to init the cookie with error_max explicitly | 15:44.29 |
| Robin_Watts | kens: The manual says it does :) | 15:44.40 |
| kens | Oh well that's reaonable :) | 15:44.51 |
| Robin_Watts | tor8: Would you rather have 0 means "any number of errors" ? | 15:45.03 |
| | rather than -1. | 15:45.30 |
| chrisl | kens: the include it as zedogs, they change the product name, and add a custom device | 15:45.33 |
| tor8 | errors_max = 1 -- abort after 1 error? | 15:45.34 |
| Robin_Watts | yeah. | 15:45.40 |
| tor8 | I think that'll be easier, then people who don't care won't have to worry about setting it | 15:45.58 |
| kens | chrisl well if they don't supply souirce then it sounds very much like GPL violations | 15:46.11 |
| Robin_Watts | tor8: I don't see this as being a particular drain on resources to maintain. | 15:46.13 |
| tor8 | Robin_Watts: not individually, but two more dozen and it will soon be | 15:46.31 |
| chrisl | kens: well, I can't find any source, and I've been all through their ftp site...... | 15:46.47 |
| kens | Report to Scott and Miles hten I think, and a thanks to tkamppeter | 15:47.14 |
| chrisl | I'm writing it up now | 15:47.32 |
| kens | :-) | 15:47.39 |
| tor8 | it's adding complexity and features that are not useful now, but will have to be maintained if they're part of the public api. adding a lot of them means it's a lot more work to refactor code. | 15:47.39 |
| Robin_Watts | tor8: I think the ability to know if we had errors during rendering is absolutely vital - it's something we've been missing. | 15:48.30 |
| tkamppeter | kens, I got the bug report https://bugs.launchpad.net/ubuntu/+source/cups/+bug/998378 at Ubuntu, a user using TurboPrint complains that images in a file do not print and I remembering that such things happened years ago, why again? | 15:48.45 |
| tor8 | Robin_Watts: yes. I agree about having an error count, that is a useful diagnostic. | 15:48.51 |
| | adding behaviour around the count, I'm not sold on | 15:48.59 |
| Robin_Watts | I guess I could live with removing error_max. | 15:49.12 |
| tkamppeter | kens, so I asked the user for some logs and sample files, all OK for me so it must be TurboPrint itself. | 15:49.19 |
| kens | Well 8.64 is pretty old. You have a remarkable memory Till | 15:49.41 |
| tor8 | Robin_Watts: if someone wants a 'strict' mode or 'bail after X errors' it will be easy to add. but even if it's easy to add now, I don't want it unless we actually use/need it. | 15:49.50 |
| tkamppeter | kens, so I installed TurboPrint and found this strange /usr/bin/gszedo and tried to execute it and found that it is Ghostscript, ancient 8.64. | 15:50.12 |
| Robin_Watts | The worry I have is that if we say "continue after every error", we might get into a seemingly infinite loop of reporting an error on every char lexed from a stream. | 15:50.14 |
| | (say when an inline image is knackered) | 15:50.45 |
| | and so we might want to limit the number of ignored errors within mudraw. But I guess we can wait until that actually becomes a problem. | 15:51.09 |
| tor8 | on the other side, a class of errors that use to work, but on a page slightly more complicated stops working because we exceed the (arbitrarily set) maximum is not good behaviour | 15:51.23 |
| Robin_Watts | tor8: yes. | 15:51.44 |
| tor8 | I'd rather catch that case where we run into pure garbage some other way, if we can figure one out. perhaps check for non-ascii chars on lexer errors? | 15:52.34 |
| Robin_Watts | I'll remove the error_max and we can worry about it when we have an example. | 15:53.19 |
| tor8 | Robin_Watts: thanks. | 15:53.34 |
| Robin_Watts | I'm happy enough in that we can add it back in painlessly if we ever do need it. | 15:54.02 |
| tor8 | I wonder if adding the try/catch around all the runkeyword will impact parsing performance though | 15:54.52 |
| | speaking of, I think we should be using sigsetjmp and siglongjmp on all platforms | 15:55.49 |
| Robin_Watts | only on platforms that have them :) | 15:56.17 |
| tor8 | we don't use signals, so saving/restoring the signal mask is rather pointless and it does have an impact on macosx (where you changed it to _setjmp already) | 15:56.59 |
| Robin_Watts | I can probably move the fz_try to be outside the do while. | 15:57.08 |
| | tor8: We could amend the code with a #ifdef sigsetjmp ? | 15:57.29 |
| tor8 | I think all non-win32 platforms have sigsetjmp | 15:57.46 |
| Robin_Watts | RISC OS doesn't. | 15:57.55 |
| d3c | Robin_Watts: will take a while to post the rest of the PDFs but I'm on it. did you get a chance to look at the other two? | 15:58.05 |
| tor8 | but sigsetjmp takes an extra argument :/ | 15:58.06 |
| | can we run mupdf on risc os? | 15:58.12 |
| Robin_Watts | d3c: Still bashing on it. | 15:58.17 |
| d3c | Robin_Watts: alright | 15:58.22 |
| tor8 | ifdef __unix then | 15:58.25 |
| henrys | alexcher:I wasn't paying any attention to the bug itself. The domain name in the email suggests that scott should try and get a support contract. | 15:58.38 |
| Robin_Watts | tor8: I'm sure I could port it in am hour or so. | 15:58.42 |
| | tor8: RISCIX doesn't have sigsetjmp :) | 15:58.57 |
| | HAVE_SIGSETJMP ? | 15:59.24 |
| tor8 | well, you can add one when porting ;) | 15:59.27 |
| Robin_Watts | and add -DHAVE_SIGSETJMP to the makefile. | 15:59.44 |
| | That way we get it by default, and people can remove it if it's a problem. | 15:59.57 |
| tor8 | of the platforms we support out of the box from the makefile, I think only win32 doesn't have sigsetjmp | 16:00.31 |
| | and the others all define __unix | 16:00.48 |
| Robin_Watts | and only win32 doesn't use the makefile. | 16:00.48 |
| tor8 | I would prefer to keep the ifdef and configurations in one place (and out of the makefiles if possible) | 16:01.29 |
| Robin_Watts | ok, so that place is where? the top of fitz.h ? | 16:01.49 |
| tor8 | but if we can't use sigsetjmp by default, add an ifdef ...linux... clause to the setjmp macros | 16:02.03 |
| Robin_Watts | I would rather have an: #ifdef __unix #define HAVE_SIGSETJMP #endif | 16:02.31 |
| | and then change the macros to use sigsetjmp if HAVE_SIGSETJMP. | 16:02.56 |
| | That way the rats nest of feature detection we end up with can all be localised. | 16:03.12 |
| tor8 | all of it's at the top of fitz.h already | 16:03.30 |
| Robin_Watts | i.e. we have 1 block of stuff that detects features, and the rest of the code works on those features. | 16:03.48 |
| | Right, but as a policy for the future, we should work to keep it there. | 16:04.02 |
| tor8 | yeah. that's quite probably better in the long run. | 16:04.09 |
| Robin_Watts | tor8: I'm looking at a SEGV reported by d3c. | 16:04.46 |
| tor8 | the whole inline and restrict keyword dance is messy too | 16:04.47 |
| d3c | Robin_Watts: here's one more: http://bugs.ghostscript.com/show_bug.cgi?id=693104 | 16:05.17 |
| Robin_Watts | It's caused by the "will a*b fit in an int" test overflowing on 64bit linux | 16:05.21 |
| tor8 | the one that came in just before the weekend? | 16:05.21 |
| d3c | Robin_Watts: that doesn't seg fault, though. just 'malloc of array (16715 x 156908 bytes) failed' and won't produce any output | 16:05.56 |
| | Robin_Watts: but returns 0 | 16:06.10 |
| Robin_Watts | d3c: Right. Thats what it's supposed to do. | 16:06.28 |
| d3c | Robin_Watts: shouldn't it return a non-zero code? | 16:07.19 |
| Robin_Watts | d3c arguably, yes | 16:08.59 |
| d3c | Robin_Watts: here's one more: http://bugs.ghostscript.com/show_bug.cgi?id=693105 | 16:09.47 |
| | Robin_Watts: it says "integer overflow" for that one | 16:09.56 |
| | Robin_Watts: same with this one: http://bugs.ghostscript.com/show_bug.cgi?id=693106 | 16:13.01 |
| Robin_Watts | tor8: In fz_malloc_array we test for UINT_MAX/size < count. | 16:13.32 |
| | but then size*count can give a negative number, and malloc of a negative number returns NULL. | 16:13.53 |
| tor8 | negative how? unsigned * unsigned == unsigned | 16:14.50 |
| | or have I misunderstood the integer promotion rules? | 16:15.08 |
| Robin_Watts | 0x264ec * 0x414b = 0x9c537d24 | 16:15.25 |
| d3c | Robin_Watts: do you need more PDFs? I have a few more | 16:15.44 |
| tor8 | malloc takes a size_t | 16:15.58 |
| Robin_Watts | tor8: OK, yes, sorry. Let me keep looking. | 16:16.54 |
| d3c | Robin_Watts: one more: http://bugs.ghostscript.com/show_bug.cgi?id=693107 | 16:18.32 |
| | Robin_Watts: and another one, this time int overflow: http://bugs.ghostscript.com/show_bug.cgi?id=693108 | 16:21.32 |
| | Robin_Watts: and here's the last one I've got: http://bugs.ghostscript.com/show_bug.cgi?id=693109 | 16:24.06 |
| | Robin_Watts: btw, I think the non-zero status code is a pretty important thing to fix since many scripts check for this to see if everything is OK (including mine). | 16:27.57 |
| Robin_Watts | tor8: Can we make 'w' 'h' and 'n' unsigned ints? (in fz_pixmap_s) | 16:28.54 |
| tor8 | that may cause trouble (and a bazillion compiler warnings) due to signed/unsigned integer comparisons | 16:29.49 |
| Robin_Watts | The alternative is to have to nobble every call to memset. | 16:30.03 |
| tor8 | have I mentioned that I really really hate the unsigned/signed crap in C? | 16:30.28 |
| Robin_Watts | Didn't give me any new warnings on linux. | 16:31.05 |
| tor8 | which memset is that? | 16:31.21 |
| | msvc is notorious about annoying warnings, but I think we disabled that specific one | 16:31.35 |
| Robin_Watts | clear_pixmap_with_value for one. | 16:31.38 |
| | I patched that and it died in a paint_span thing. | 16:31.54 |
| tor8 | do we run into a >2 gigapixel image? | 16:32.25 |
| Robin_Watts | yeah, lots of warnings from MSVC | 16:32.36 |
| | yes. | 16:32.38 |
| tor8 | ouch. | 16:32.43 |
| Robin_Watts | more than a 2gigabyte image. | 16:32.45 |
| | but d3c is running at 2000 dpi :) | 16:33.01 |
| tor8 | well, we could add in 'unsigned int's where they make sense, but then we should have a go at adding in const and being anal about using the right int everywhere ... a *lot* of trouble really | 16:33.44 |
| | I grumbled a lot when we made the malloc functions take unsigned ints too! | 16:34.06 |
| | we touch pixmap->w/h/n in a lot of places though don't we? | 16:34.26 |
| | all those loop counters should be turned into unsigned ints too, for correctness sake, if we make pixmap.w/h/n unsigned | 16:34.56 |
| | and that's ... ugly | 16:35.06 |
| | Robin_Watts: fz_throw(ctx, "overly wide image"); ... extend that check perhaps, to check all dimensions? | 16:37.46 |
| | fixing the memset won't catch our other accesses | 16:38.38 |
| | and unsigned int w, h, n won't catch the signed loop counters | 16:38.55 |
| Robin_Watts | I'm trying to solve this without changing w/h/n to unsigned. | 16:39.18 |
| tor8 | so to be sure, we should either not allow >2gb pixmaps or make everything unsigned (and then still hit a hard limit at 4gb) | 16:39.32 |
| | so I think limiting them is the sanest choice | 16:39.43 |
| | d3c should be running in bands, at 2000 dpi :) (or is this hitting some other internal pixmaps?) | 16:40.31 |
| Robin_Watts | Ah. I see the problem. | 16:43.29 |
| | dp = dst->samples + ( (y - dst->y) * dst->w + (x - dst->x) ) * dst->n; | 16:43.49 |
| | the offset is calculated as a signed int, overflows and becomes negative. | 16:44.06 |
| | before it gets promoted to a 64bit pointer value. | 16:44.37 |
| | hehe. I bet ray will be on here in a mo, asking why peeves is thrashing... | 16:46.22 |
| henrys | alexcher:now just email scott and give him the guys email address and copy in support so we know it has been processed, that's the procedure we agreed to use. It falls on you because the bug is assigned to you. | 17:04.05 |
| alexcher | henrys: OK | 17:11.37 |
| henrys | Robin_Watts:how was your 1/2 Marathon? | 17:13.45 |
| | chrisl:so are we good on changing the headers? | 17:14.01 |
| Robin_Watts | henrys: Was just me running around the village. Was slow. | 17:14.06 |
| henrys | I got the new garmin it has an acceloremeter in it - counts laps and strokes in the pool. | 17:16.38 |
| Robin_Watts | henrys: ooh. which one? | 17:17.01 |
| Robin_Watts | has to go pick helen up. bbs. | 17:17.36 |
| henrys | 910XT | 17:17.46 |
| Robin_Watts | Ah, excellent. They've gone back to sensible things rather than touchscreens which don't work when wet/sweaty. | 17:18.41 |
| chrisl | henrys: I'm good to do the headers soon-ish - I didn't get a script put together because I got distracted doing these library updates, but I really wanted to get that done | 17:19.10 |
| henrys | I don't know a happy touchscreen customer what a flop... | 17:19.17 |
| | chrisl:another tedium task after that one. We want to somehow get gsprint into the release completely with GPL and all. | 17:20.15 |
| | tedious | 17:20.25 |
| chrisl | Hmm, I don't know anything about gsprint...... | 17:21.17 |
| henrys | that makes 2 of us. | 17:23.22 |
| | I wonder if a windows user should investigate this one. | 17:24.50 |
| chrisl | Do we just want it included in the release, or do we want it integrated into the builds, for example? | 17:25.43 |
| henrys | just included | 17:27.00 |
| chrisl | OKay, let me have a look at it, and if I get confused, I'll foist it onto a regular Windows user | 17:27.35 |
| henrys | and change the license I believe it is AFPL | 17:27.56 |
| chrisl | Noted..... | 17:28.21 |
| henrys | and we'll need some way to get rid of the wisc pages. | 17:32.23 |
| chrisl | You mean references to them, or the actual pages? I still have access to what remains of the wisc site | 17:33.09 |
| henrys | once we've assimilated gsprint it seems http://pages.cs.wisc.edu/~ghost/gsview/gsprint.htm should become a gs "doc" page and the original removed, right? | 17:46.47 |
| chrisl | Yes, that should happen. wisc seems to be gradually disappearing, anyway..... | 17:47.59 |
| henrys | unfortunately we can't do all of gsview for financial reasons. | 17:48.10 |
| | gsprint and redmon we can do. | 17:48.56 |
| chrisl | I'm heading off - g'nite all | 17:55.32 |
| kens | Night chrsil | 17:55.38 |
| | Think I'll head off too | 17:55.45 |
| mace_ | anyone heard from miles recently, or is he off galavanting? :) | 18:49.30 |
| henrys | I just got mail from him. | 18:50.08 |
| Robin_Watts | He's at a trade show this week. | 18:50.09 |
| | (or will be) | 18:50.15 |
| henrys | I thought it was just scott and michael | 18:50.47 |
| | I might be mistaken though | 18:50.59 |
| Robin_Watts | oh, maybe. | 18:51.01 |
| d3c | Robin_Watts: did you guys figure out anything regarding the bugs I reported? :) | 18:51.13 |
| Robin_Watts | d3c: Just committing a fix now. | 18:51.25 |
| d3c | Robin_Watts: oh, sounds nice. was it the same bug for all reports? | 18:51.56 |
| Robin_Watts | d3c: No idea. Just made the first one work. I'll look at the others now/later/tomorrow. | 18:52.56 |
| d3c | Robin_Watts: ah, ok. I'll see if it fixes the others and get back to you | 18:53.16 |
| Robin_Watts | oh, balls. I left the reference to error_max in the commit message. | 18:55.07 |
| | tor8: ping | 18:55.12 |
| Robin_Watts | performs git surgery. No one saw that. | 18:57.31 |
| henrys | I just created a bug with a private attachment and can't access it unless I'm logged in. How did I manage that. | 19:10.19 |
| | ? | 19:10.20 |
| | can't access the entire bug that is, I shouldn't be able to access the attachment. | 19:13.31 |
| Robin_Watts | henrys: What number? | 19:15.10 |
| | 693110 is showing with a padlock by it in the list. | 19:16.06 |
| henrys | 693110 | 19:16.07 |
| d3c | Robin_Watts: did the git surgery work out? | 19:16.42 |
| Robin_Watts | d3c: Yes thanks. | 19:16.49 |
| d3c | Robin_Watts: alright, thanks. I'll check it out soon | 19:17.09 |
| henrys | when I created the bug I chose "can access private attachments" that was wrong. not sure if I can undo it without creating a new bug. | 19:19.32 |
| Gigs- | can someone msg me mvhrel's email | 19:21.07 |
| | thanks | 19:21.44 |
| Robin_Watts | np. | 19:21.50 |
| | tor8: "1086 - rlebomb.pdf" is exactly the kind of thing I was worried about. | 19:26.55 |
| henrys | alexcher can you move your comment to 693111 I screwed up the creation of that initial bug. | 19:33.39 |
| | marcos is probably laughing at me, can't even fill out the new bug report form right... | 19:39.59 |
| d3c | Robin_Watts: output changed a bit for the malloc issue with your latest commit. see http://bugs.ghostscript.com/show_bug.cgi?id=693103 | 20:09.36 |
| | Robin_Watts: I'm testing right now to see if it solves the seg fault issue as expected | 20:10.56 |
| tor8 | Robin_Watts: I'll look tomorrow. I've got a head ache, so should go lie down and not sit at a glowing screen anymore. sorry. | 20:34.05 |
| henrys | watching live footage of a huge fire near me. It's hard to imagine these helicopters have much effect, they seems so insignificant. | 20:37.57 |
| d3c | Robin_Watts: gotta go. good job with the bugs today - thanks. | 20:55.53 |
| ianneub | Howdy all, I made a quick change to mupdf that let's you output a png file to stdout, thought I would share it incase anyone else wanted to see it: http://pastie.org/4069877 | 21:22.04 |
| Robin_Watts | Gah. | 23:53.36 |
| | Tor's test scripts produce an output html page where it shows differences in the stdout differences side by side (old then new) | 23:54.10 |
| | Then they show the differences in images (new, diff, old) | 23:54.26 |
| | Forward 1 day (to 2012/06/12)>>> | |
IRC Logs