| | <<<Back 1 day (to 2015/03/15) | 20150316 |
| mulover | Hey there! Any idea on this one? http://bugs.ghostscript.com/show_bug.cgi?id=695870 | 10:37.37 |
| | Mudraw fails an rendering some dotes in the given pdf. GS does fine. | 10:37.38 |
| kens | You opened a bug report 4 minutes ago and you want an answer already ? O.O | 10:38.50 |
| mulover | Sorry. I used the bug report to upload the files and make things more easy and i am just interested if this is known. Did not want to upset anyone! | 10:40.03 |
| tor8 | mulover: not to worry. doesn't look like a known problem to me. | 10:41.12 |
| kens | I can't see any good reason for it, the PDF has nothing especially weird | 10:41.27 |
| | Apart from sticking all the content in a form for no good reason | 10:41.44 |
| tor8 | kens: I suspect the "[]0 d" | 10:41.49 |
| kens | Ah :-) | 10:41.57 |
| | I htink GS has special handling for that | 10:42.06 |
| | I seem to remember seeing it | 10:42.15 |
| tor8 | but I'd have to be properly awake to tackle that :) | 10:42.17 |
| kens | [] 0 d is one of the examples in Table 4.6 its supposed to be a solid line | 10:43.17 |
| tor8 | it could also possibly be a < vs <= or numeric precision issue with a dash at the very end of a stroke | 10:43.27 |
| kens | I'd suspect the latter | 10:43.57 |
| | But I cna check, I can alter the file :-) | 10:44.08 |
| mulover | Im glad that this at least might be an interesting one ;-) | 10:44.19 |
| kens | MuPDF is quite happy with the '[] 0 d' and properly draws a solid line | 10:45.53 |
| | SO I'd supect its a dash being dropped at the end of the line inappropriately. | 10:46.43 |
| tor8 | kens: I've cut it down to just one segment | 10:48.05 |
| | mupdf draws 8 dots, gs draws 9 | 10:48.10 |
| kens | Yeah that's easier | 10:48.13 |
| tor8 | and adjusting the dash spacing makes more or fewer dots appear- | 10:48.31 |
| kens | From what I can see the last dash goes missing | 10:48.32 |
| | So I'll go back to CIDMaps...... | 10:48.49 |
| Robin_Watts | Aha, a tor8. | 10:57.59 |
| | Lots of commits on robin/master for you to look over. | 10:58.10 |
| Aqualon | Hello, I've a question about substr and substring. Is there any reason why substr function is missing in MuJS? | 11:13.43 |
| tor8 | Aqualon: the substr function is deprecated | 11:14.03 |
| Aqualon | Hmm, seems that this is a valid reason ;) | 11:14.57 |
| tor8 | escape, unescape, String.substr, Date.getYear, Date.setYear and Date.toGMTString are deprecated "compatibility" functions that we don't implement in MuJS | 11:15.43 |
| | if you need them, they should be trivial to implement in JS | 11:16.13 |
| | Robin_Watts: I don't understand the 64-bit memtrace changes | 11:22.11 |
| | shouldn't the macro be FZ_SIZE_FMT ? | 11:23.07 |
| Robin_Watts | tor8: Yes, probably. Will fix. | 11:23.46 |
| tor8 | and we use our own printf in places, should probably use our own printf everywhere to be consistent | 11:24.04 |
| | and how does that handle size_t? | 11:24.10 |
| | might be easier to just use our own printf and have a separate character for size_t | 11:24.34 |
| | though that's a bigger change | 11:24.53 |
| Robin_Watts | tor8: The trace_header stuff is used because we need to keep jmpbuf's aligned. | 11:25.10 |
| tor8 | I'd rename quadto as conicto (to match freetype's terminology) and put it before the close callback | 11:25.49 |
| Robin_Watts | ok. IA64 and AMD64, malloc blocks are 16 byte aligned. Sticking an 8 byte size_t in before each block breaks that. | 11:26.17 |
| | It's after the close callback because it is implemented less often. | 11:26.40 |
| tor8 | Robin_Watts: ah. malloc padding trickery. | 11:26.47 |
| | putting it last will make me have to look up the order every time | 11:27.14 |
| | does the caller check null and call curveto if it is missing? | 11:27.29 |
| Robin_Watts | Yes. | 11:27.35 |
| | There are hline, vline and rect entries too. | 11:27.48 |
| | all those follow close, cos they are the most rarely implemented ones. | 11:28.09 |
| tor8 | Robin_Watts: okay, so the small patches all look good, need to study the path packing and name rework a bit more | 11:29.15 |
| | the pdf_update_stream one is something I tackled (probably slightly differently) on my pdf_csi branch | 11:29.34 |
| | I discovered that our ftoa() function is broken and I'm too stupid to fix it | 11:29.53 |
| Robin_Watts | In what way is it broken? | 11:30.12 |
| tor8 | 5536 turns into 5536.00012 something | 11:30.24 |
| kens | chrisl ping | 11:31.55 |
| Robin_Watts | SIZE_FMT updated to FZ_SIZE_FMT | 11:32.15 |
| chrisl | kens: pong | 11:32.18 |
| kens | I have a PDF file which is geneerating a CIDMap and I cannot figure out *where* the CIDMap is coming form, if I send you the PDF file can you tell me ? | 11:32.48 |
| Robin_Watts | tor8: Our fz_printf relies on having a context. | 11:33.26 |
| chrisl | Maybe.... | 11:33.26 |
| kens | FWIW the problem is that the CIDMap is 2 bytes less than I expect | 11:33.28 |
| | Well I'll send you the font :-) | 11:34.09 |
| | Err file | 11:34.16 |
| tor8 | Robin_Watts: also, I'd change all the path callbacks to take the fz_context* argument explicitly | 11:36.19 |
| Robin_Watts | tor8: I deliberately avoided that for speed. | 11:36.52 |
| | If the user needs a context, put it in the arg. | 11:37.10 |
| tor8 | then f.ex. svg_path_moveto doesn't have to spend time dereferencing a struct pointer to extract the ctx and out parameters | 11:37.18 |
| | *everything* needs a context. pass it. | 11:37.28 |
| | given that we have the choice of passing it, or extracting it, I don't see a performance implication | 11:37.50 |
| Robin_Watts | not everything needs it. Some things just pass it through. | 11:38.23 |
| tor8 | very rarely, and I want consistency or I wouldn't have spent the time (and pain for our customers) to make all the APIs regular | 11:38.47 |
| Robin_Watts | I'll do a commit to pass it and compare the speeds. | 11:39.03 |
| tor8 | only to have you come and ruin things one week later :) | 11:39.06 |
| Robin_Watts | :) | 11:39.16 |
| | It's not a 'public' api really. | 11:39.29 |
| | and the change was to avoid 'bound' contexts that persist. | 11:39.47 |
| tor8 | but *I* need the regularity for code I work on :) | 11:39.51 |
| Robin_Watts | The fz_path_process stuff doesn't persist. | 11:40.00 |
| tor8 | true, that was one of the largest motivators | 11:40.04 |
| Robin_Watts | but yes, regularity is nice as long as it's not noticeably slower. | 11:40.23 |
| | I'll give it a spin later. | 11:40.38 |
| tor8 | an explicit argument makes most of the code to handle paths shorter and simpler though | 11:41.00 |
| | the svg_path_device would take a fz_output and the pdf_dev would just take a fz_buffer | 11:41.13 |
| Robin_Watts | On the whole I like the fz_path_process stuff as it keeps the path implementation local to path.c | 11:41.16 |
| | tor8: yeah. | 11:41.23 |
| tor8 | yes, I don't object to the callback based path stuff :) | 11:41.35 |
| Robin_Watts | I am almost tempted to add support for 'smooth' beziers to the path stuff too. | 11:42.08 |
| tor8 | but forcing everybody to make a struct just to wrap the context up together with what it needs irks me | 11:42.14 |
| Robin_Watts | yeah. | 11:42.24 |
| tor8 | as long as the path walker can decompose everything into the 4 primitives, I won't object too loudly | 11:42.53 |
| Robin_Watts | we'd need both 'smooth' and 'arc' added to the path stuff to be able to keep xps paths entirely intact. | 11:42.57 |
| tor8 | ick. arcs. | 11:43.08 |
| Robin_Watts | I only found about about smooth and arc while looking for a mistake this morning, so haven't thought them through. | 11:43.30 |
| | smooth is relatively easy though. | 11:43.43 |
| tor8 | I don't really like it. but it will be used for SVG as well, since I believe that's where XPS got its path syntax | 11:44.11 |
| Robin_Watts | I've got a customer SOT thing to look at now, but would like to get this stuff hammered on and in before the release. | 11:45.12 |
| tor8 | Robin_Watts: okay. the path stuff looks good as long as you fix the fz_context thing | 11:46.20 |
| | and I guess we can start using int8_t etc everywhere now? no icky #ifdef voodoo required to get them defined? | 11:47.16 |
| chrisl | Hmm, my Win7 laptop has been booting for ~10 minutes now, and still hasn't reached the desktop (or even any informative display) - that can't be good :-( | 11:47.56 |
| Robin_Watts | tor8: I personally would prefer the {u}int{8,16,32}_t stuff to unsigned short etc. | 11:48.07 |
| tor8 | please wait a bit before you push the path packing commit | 11:48.52 |
| Robin_Watts | If a compiler doesn't support {u}int{...}_t then it's a trivial matter to wrap it. | 11:48.55 |
| | tor8: sure. I'll check back before I commit anything. | 11:49.06 |
| tor8 | and I want to see how the name change would look like with global objects instead of pointer trickery | 11:49.10 |
| Robin_Watts | tor8: yeah. | 11:49.18 |
| tor8 | Robin_Watts: I'd say go for it. let's jus {u}int{8,16,32}_t where we need specific sizes, and size_t like you did for the 64-bit changes | 11:50.01 |
| | s/jus/use/ | 11:50.15 |
| Robin_Watts | I wish we had ssize_t, but it doesn't seem to be supported on windows :( | 11:50.24 |
| tor8 | signed size? | 11:50.30 |
| Robin_Watts | so I've been using ptrdiff_t | 11:50.31 |
| | yeah. | 11:50.33 |
| tor8 | typedef it :) | 11:50.36 |
| | I've used ptrdiff_t and intptr_t before IIRC | 11:50.49 |
| Robin_Watts | I've used intptr_t before too. | 11:51.05 |
| tor8 | ah. well, I'd #ifdef _WINxx and add ssize_t if it's part of the C standard | 11:51.18 |
| | http://pubs.opengroup.org/onlinepubs/007908775/xsh/systypes.h.html it's here, so I say add it to the system.h ifdef chunks if it's missing | 11:52.08 |
| chrisl | kens: I didn't get a file - should I have? | 11:52.17 |
| kens | Grr Eudora not sent email, one moment | 11:52.36 |
| tor8 | Robin_Watts: question though, should we use off_t for the file reading functions? | 11:52.49 |
| kens | OK its gone. | 11:52.51 |
| | I'm not sure exactly where the problem lies. | 11:53.06 |
| | I'm looking at glyph 117, but the CIUDMap only contains 234 bytes, if you include 0, then that should be 236. However I have a sneaky suspicion the font is declaring the wrong number of CIDs or something | 11:53.58 |
| Robin_Watts | off_t being ssize_t ? | 11:54.02 |
| tor8 | off_t depends on FILE_OFFSET64 | 11:54.30 |
| kens | chrisl which is why I want to find where the Identity CIDMap is being created | 11:54.32 |
| Robin_Watts | tor8: It would be nice to lift the 32bit limit on pdfs. | 11:54.45 |
| tor8 | and off_t is signed | 11:55.14 |
| | it would be nice | 11:55.19 |
| Robin_Watts | At the moment, the '64bit tweaks' commit goes some way to lifting that (but it will fail as we still use 32bit file access methods) | 11:57.05 |
| | It would be nicer to use off_t and 64bit file access methods so that we can choose whether to support large files in both 32 and 64bit builds. | 11:57.38 |
| tor8 | yeah. we can do that as a later enhancement. I'll add it to my todo list. | 11:57.39 |
| | revamping the code to use uint8_t etc for all the draw device, encoding filters and binary parsing would be nice too | 11:58.00 |
| | and of course, using our own printf and fz_output and fz_buffer for all the I/O stuff we do | 11:58.45 |
| chrisl | kens: I'd assume the Identity CIDMap is coming from /GenerateIdentityCIDMap | 12:00.13 |
| kens | Hmm, I don't think it got into there but I'll check again, thanks chrisl | 12:00.36 |
| chrisl | Well, it depends on the font - it may be /GenerateCIDMap | 12:01.03 |
| kens | I had == in both, and neither triggered, but I maybe made a mistake | 12:01.23 |
| tor8 | Robin_Watts: I also believe the commits on tor/csi are good to go; whenever you've got some time over | 12:01.44 |
| Robin_Watts | tor8: will look now. | 12:01.54 |
| | tor8: I prefer my fix for pdf_update_stream, I think. | 12:03.14 |
| chrisl | kens: ah, no, it's coming from /.definettcidfont in gs_ttf.ps | 12:03.26 |
| kens | Aha, that would explain it! | 12:03.38 |
| | THanks | 12:03.50 |
| Robin_Watts | In every case where we call pdf_update_stream we update the Length thing, so it makes sense to roll the two together. | 12:03.52 |
| chrisl | kens: and it is based on the size of the loca table | 12:04.23 |
| kens | OK so I guess now I need to decode the font and see, I wouldn't be surprised to find its incorrect. | 12:04.49 |
| tor8 | Robin_Watts: yeah, that's what my commit does too, but it also takes an argument about whether to nuke the /Filter and /DecodeParms entries as well | 12:04.50 |
| | otherwise they look very similar | 12:04.55 |
| Robin_Watts | tor8: ah. | 12:05.09 |
| kens | Though having said that, it sets CIDCount to numlopca | 12:05.12 |
| Robin_Watts | tor8: Then I think I probably prefer yours. | 12:06.06 |
| kens | OK so numloca is indeed 117, but I have glyphs numbered 0->117. | 12:06.32 |
| tor8 | my only gotcha is that I'm not sure I do the right thing for pdf-write.c make_hint_stream where I flagged it with an // XXX comment | 12:07.03 |
| | but looking at yours, I think I do the same | 12:07.26 |
| Robin_Watts | There are some // XXX comments in the "Don't pass interpreter context" commits too. | 12:09.13 |
| tor8 | ah, yes! now I remember what I haven't done yet. | 12:09.45 |
| | OCGs :( | 12:09.47 |
| Robin_Watts | and pdf_clean_stream_object looks to be commented out. | 12:09.48 |
| | return Memento_label(fz_calloc(ctx, 1, size), "pdf_processor"); | 12:10.25 |
| tor8 | yeah, pdf_clean is nuked in that commit and reinstated in a later commit | 12:10.28 |
| Robin_Watts | That might as well be return fz_malloc_struct(ctx, pdf_processor); | 12:10.45 |
| chrisl | kens: what's the numGlyphs entry in the maxp table in the font? Maybe we should be using that for the CIDMap? | 12:10.47 |
| tor8 | Robin_Watts: no, because the 'size' is not sizeof pdf_processor | 12:11.01 |
| kens | Not sure yet, one moment. I can say that hte loca table is 236 bytes | 12:11.06 |
| Robin_Watts | D'Oh! | 12:11.13 |
| tor8 | I've used the same approach for fz_devices and fz_documents | 12:11.41 |
| kens | chrisl numGlyphs=117 | 12:11.47 |
| tor8 | fz_new_document takes the sizeof the superclass and initializes in the fz_document part | 12:11.58 |
| chrisl | Hrm :-( | 12:12.01 |
| tor8 | and returns a void* | 12:12.05 |
| kens | chrisl so it seems the font is bad, not surprising given that it is missing several *required* tables. | 12:12.23 |
| Robin_Watts | tor8: yeah, makes perfect sense. | 12:13.04 |
| | So I'll leave that lot until you've done OCGs. | 12:13.14 |
| kens | chrisl so I think that I'm going to pass on this and say to the reporter 'the font is bogus, get tesseract to fix it' | 12:13.26 |
| tor8 | Robin_Watts: okay. and I can squash them into one if that would help reviewing later. | 12:13.51 |
| kens | lunches | 12:13.56 |
| chrisl | kens: yeh, I'd say so - numGlyphs is "The number of glyphs in the font.", so it is wrong | 12:14.00 |
| Robin_Watts | tor8: possibly, yes :) | 12:14.02 |
| tor8 | and now I'll go cry in a corner for a bit contemplating OCGs :( | 12:14.24 |
| kens | chrisl I suspect the tesseract folks didn't realise that they need a /.notdef and need to start from 0 :-) | 12:14.32 |
| chrisl | kens: that's why I checked the spec, in case numGlyphs was allowed to ignore the notdef..... | 12:15.15 |
| Robin_Watts | tor8: I prefer quad rather than conic. It matches xps and svg's usage. | 13:11.02 |
| | and truetype, I think. | 13:11.31 |
| | and flash for that matter. | 13:11.39 |
| tor8 | Robin_Watts: okay. | 13:13.53 |
| Robin_Watts | hmm. Looking at putting the explicit fz_context's back in now. | 13:14.20 |
| | fz_stroke functions all benefit from having it hidden. | 13:14.58 |
| | Without fz_context: 3:42:51. With fz_context: 3:44:56 | 13:44.35 |
| tor8 | Robin_Watts: cluster timings? | 13:57.05 |
| | a ~1% difference is difficult to measure accurately | 13:58.59 |
| | do you have measurements from before you made it callback based? | 13:59.28 |
| kens | chrisl looks like time to kill pf2afm to me :-) | 14:02.50 |
| chrisl | kens: fine by me..... | 14:03.13 |
| kens | Its your bug :-) | 14:03.23 |
| | Oh and its severity is 'major' of course | 14:04.00 |
| chrisl | not any more..... | 14:04.34 |
| kens | LOL | 14:04.39 |
| chrisl | Even better...... | 14:25.49 |
| kens | So it works with current code ? ROFL | 14:29.15 |
| chrisl | It works with the last release - so there's really no excuse | 14:30.03 |
| kens | None at all, no | 14:30.12 |
| Robin_Watts | tor8: Any cluster tests we run will compare with the existing trunk time. | 14:33.37 |
| | so we can cluster test any commit we want for timings. | 14:33.46 |
| chrisl | The cluster timings are not trustworthy, in my experience | 14:34.16 |
| Robin_Watts | The change to the name commits saved time. 9 minutes or so, to 3:51: iirc. | 14:34.19 |
| | chrisl: They seem largely stable for mupdf at least. I ran several tests back to back a while ago. | 14:34.42 |
| chrisl | Well, they bounce all over the place for Ghostscript/GhostPDL | 14:35.12 |
| Robin_Watts | I can't comment on that, but it doesn't really surprise me. | 14:35.27 |
| chrisl | Possibly gs relies rather more on disk throughput than mupdf for the regression testing | 14:36.03 |
| | kens: when you have a minute, can I get you to cast your eye over two commits? | 15:00.15 |
| | http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=19c485b4 | 15:00.20 |
| kens | I'll do it now | 15:00.28 |
| chrisl | http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=8b6a5ca | 15:00.30 |
| kens | Well I cna't say I like the 'aux' but its pretty standard in GS :-( Apart from that it looks pretty good to me. It would take me a long time to be thorough on checking it of course. | 15:04.37 |
| | That's both commits. | 15:04.54 |
| chrisl | Would you prefer "_impl"? ;-) | 15:05.03 |
| kens | Not really :-) | 15:05.11 |
| | aux is actually better in this case I htink. Like I said, its too late to start complaining about it now.... | 15:05.30 |
| chrisl | I'm not tied to the name, but I don't want to duplicate the code in two places..... | 15:05.42 |
| kens | No, its fine, aux makes more sense than 'impl' here anyway | 15:06.05 |
| | THe code looks good, but of course its always hard to be sure with PostScript. | 15:06.18 |
| | I certainly don't see any glaring problems | 15:06.32 |
| chrisl | OKay, thanks - I'm sure someone will tell us if it doesn't do what they want! | 15:07.12 |
| kens | No doubt :-( | 15:07.25 |
| chrisl | Whatever way you look at it, it was quite wrong before | 15:08.12 |
| kens | Someone will probably be relying on its bizarre behaviour :-( | 15:08.50 |
| chrisl | Tough! | 15:09.05 |
| kens | Wow its 3 pm where did the day go ? | 15:09.30 |
| dokma | hey guyz, gs is spewing some glyph errors when merging. how can I find out which pages are in question? | 15:18.58 |
| | gs -dBATCH -dNOPAUSE -q -sDEVICE=pdfwrite -sOutputFile=out.pdf `ls BERTHOUD_p*` | 15:18.59 |
| kens | OK first you are not 'mering' you are producing a new PDF file whose marking content is given by the 2 input files. The new file has nothing in common with the original files except the appearance. | 15:20.15 |
| | After that, we can't possibly comment without seeing the files. If you want to investigate it yourself, then reduce the files by removing pages. | 15:21.16 |
| chrisl | dokma: one idea might be to not tell Ghostscript to minimise it's feedback when running the file(s) | 15:22.08 |
| rayjj | chrisl: kens: or Robin_Watts: can one of you look at the temporary fix (hack) for bug 695711 on my repos | 15:45.10 |
| Robin_Watts | looking now. | 15:45.20 |
| kens | Beat me to it | 15:45.37 |
| rayjj | Robin_Watts: BTW, bmpcmp is giving me an error I've never seen before: http://www.ghostscript.com/~regression/ray | 15:46.08 |
| Robin_Watts | rayjj: Seems sane enough. | 15:46.11 |
| rayjj | Robin_Watts: thanks. It's a hack but it's better than a segfault | 15:46.30 |
| kens | rayjj I htink that usually happens for me when macpro disk fills up | 15:46.59 |
| Robin_Watts | rayjj: That bmpcmp error generally means that either the old version or the new version failed to produce a bitmap. | 15:46.59 |
| | (or what kens said :) ) | 15:47.13 |
| rayjj | and given that we sometimes ignore BGPrint=true and/or NumRenderingThreads (eg. if the build doesn't support threads) | 15:47.27 |
| Robin_Watts | malc_: Hey. | 16:11.37 |
| | That j1.pdf. | 16:11.39 |
| | I have some commits on robin/master that get its memory use down to 2Gig or thereabouts. | 16:12.06 |
| | bah. | 16:12.08 |
| rayjj | trying bmpcmp again with macpro disabled | 16:19.14 |
| kens | Err it might not be macpro, I wouldn't trust my memory on these things (well anything, really) | 16:19.40 |
| rayjj | kens: that's OK. bmpcmp is fast enough, and I committed the patch anyway | 16:20.05 |
| | kens: I forgot to ask. Were Stella and Melanie impressed by the story of your wipeout at Copper (or did you not tell them so they let you keep skiing ;-) ) | 16:21.49 |
| kens | THey were more interested in the flight home..... | 16:22.04 |
| rayjj | kens: yeah, that too :-( | 16:22.15 |
| | Robin_Watts: do you know if the cluster test runs the old version with the "extras" params ? If so, then it may be that the old version segfaulted (silently) on those tests and the new version worked | 16:23.50 |
| Robin_Watts | rayjj: Offhand, no. | 16:24.10 |
| rayjj | bmpcmp gave the same results, so I guess it wasn't macpro | 16:25.39 |
| chrisl | rayjj: I don't know if you noticed Bug 695862 - but the root of the problem is that the "fake" recursive pthread mutex stuff in Ghostscript is broken | 16:25.48 |
| rayjj | chrisl: yeah, I've been seeing those bugs go past | 16:26.17 |
| chrisl | rayjj: I've coded up a solution so if they are available we'll use pthread recursive mutexes, and if not, we'll emulate them properly | 16:26.59 |
| rayjj | chrisl: great! Do you have a patch to review ? | 16:27.55 |
| | chrisl: and, of course, I'd be curious to see if that was the cause of bug 695711 | 16:28.34 |
| rayjj | on phone with cust 532... | 16:28.49 |
| chrisl | rayjj: yeh, so as background: the current implementation relies on it being safe to unlock an unlocked mutex, which pthreads classifies an undefined behaviour - *something* inside pthreads has changed recently that means it crashes...... | 16:30.10 |
| | rayjj: patch for review: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=06234037 | 16:30.23 |
| | rayjj: actually, I just noticed a small snafu in the error handling, so slight revision for review: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=da497ca1334 | 16:34.31 |
| mvrhel_laptop | rayjj: what ever happen to the altona bugs you were going to open? | 16:36.41 |
| | oh he is on phone with them now | 16:37.38 |
| rayjj | mvrhel_laptop: off the phone now. Their main focus today is on the 1-bit thresholding in the device code that I've given them (cleaning up the integration and testing) | 16:40.45 |
| mvrhel_laptop | that should keep them busy... | 16:41.17 |
| rayjj | mvrhel_laptop: but I do need to understand what modes are supposed to work. | 16:41.19 |
| | eg. not opening bugs for modes that can never work. | 16:41.59 |
| mvrhel_laptop | rayjj: I just opened the file in AR pro and I toggle the output profile and see the huge changes | 16:42.20 |
| rayjj | mvrhel_laptop: but even with Acrobat 'overprint preview' turned off and going to PNG RGB, we don't match either our RGB or our CMYK output | 16:43.01 |
| | mvrhel_laptop: on which pages ? | 16:43.35 |
| mvrhel_laptop | who is we and what do you mean our? | 16:43.44 |
| Robin_Watts | Did we ever have a >4Gig PDF file to test? | 16:44.08 |
| mvrhel_laptop | rayjj: I think I listed the paged in the IRC | 16:44.58 |
| | let me find it | 16:46.18 |
| rayjj | mvrhel_laptop: what are you doing to change output profile with AR Pro ? (I have 9) and I change Preferences/Color Management settings and don't see the kinds of changes on p7 that we get changing colorspace or OutputICCProfile | 16:46.25 |
| | p7 is pretty dramatically different | 16:47.00 |
| mvrhel_laptop | rayjj: Advanced->Print Production->Output Preview | 16:47.27 |
| | rayjj: Change the Simulation Profile | 16:47.43 |
| | let me reopen the file | 16:48.00 |
| | AR used the output intent profile by default | 16:48.30 |
| rayjj | mvrhel_laptop: I don't see "Simulation Profile" listed in AR Pro 9 | 16:48.31 |
| mvrhel_laptop | Mine has it | 16:48.38 |
| | in the output preview window | 16:48.52 |
| | at the top | 16:48.54 |
| kens | Mine has it too (Acrobat 9 Pro) | 16:49.20 |
| | On WIndows | 16:49.23 |
| mvrhel_laptop | yes | 16:49.25 |
| | Windows AR Pro 9 | 16:49.33 |
| kens | Don't know about reader, mine is the full acroabt | 16:49.51 |
| mvrhel_laptop | oh its not Reader | 16:49.59 |
| | sorry | 16:50.01 |
| | Just Acrobat | 16:50.03 |
| kens | X is a little different | 16:50.07 |
| | But its still there | 16:50.20 |
| rayjj | mvrhel_laptop: where is the Output Preview Window ? | 16:51.07 |
| mvrhel_laptop | hehe | 16:51.19 |
| rayjj | mvrhel_laptop: I have Acrobat Pro 9 | 16:51.23 |
| mvrhel_laptop | Advanced->Print Production->Output Preview | 16:51.28 |
| kens | Advanced menu | 16:51.30 |
| mvrhel_laptop | top menu | 16:51.34 |
| | bar | 16:51.36 |
| kens | Its not on Reader | 16:51.37 |
| mvrhel_laptop | also, in gs, to match Acrobat we would probably want to use -dUsePDFX3Profile to use the output intent profile and go out to a CMYK device | 16:52.20 |
| rayjj | mvrhel_laptop: Ah, Now I see it | 16:52.22 |
| mvrhel_laptop | rayjj: so it should by default be set to the output intent profile | 16:52.54 |
| | but you can change it to sRGB | 16:53.01 |
| | and you should see some large changes | 16:53.07 |
| | page 7 is quite different | 16:54.21 |
| | the C on the left | 16:54.26 |
| | big change in the transparency in fact | 16:54.35 |
| | rather interesting | 16:54.55 |
| | the point is that this file is made to be very sensitive to this sort of thing | 16:55.10 |
| | if you are not going to do real color management in the output intent color space, then you are going to have a tough time matching | 16:55.31 |
| | now, if gs with -dUsePDFX3Profile to use the output intent profile and going out to a CMYK device we should be darn close. if not, I would call that a bug | 16:56.08 |
| rayjj | mvrhel_laptop: we seem to match Adobe pretty well if I set "CIE RGB" as the Simulation Profile. The leftmost D is the only major difference | 16:56.54 |
| mvrhel_laptop | rayjj: we match with what set up for gs? | 16:57.29 |
| | with the customer's set up? | 16:57.53 |
| rayjj | mvrhel_laptop: with gswin32c -r300 (no other params, thus RGB default mode) | 16:58.51 |
| mvrhel_laptop | I see | 16:58.59 |
| rayjj | and page 15 is almost an exact match then | 16:59.21 |
| mvrhel_laptop | good deal | 16:59.27 |
| rayjj | mvrhel_laptop: so for now, I will compare against these Acrobat settings and open bugs. | 17:02.40 |
| mvrhel_laptop | rayjj: seems reasonable to me | 17:02.59 |
| rayjj | mvrhel_laptop: and so I understand. Do we have anything that tries to do Overprint Preview on RGB devices (that has a prayer of working) ? | 17:04.07 |
| mvrhel_laptop | hehe. By default it should be attempting it as best it can | 17:04.30 |
| | you can turn it off | 17:04.54 |
| rayjj | mvrhel_laptop: so there are now 'options' needed for it ? | 17:04.57 |
| | mvrhel_laptop: oh, how do I turn it off ? | 17:05.07 |
| | (to compare current gs with what they are getting which is an old 9.06 code base) | 17:05.35 |
| mvrhel_laptop | -dSimulateOverprint = true/false | 17:05.43 |
| rayjj | mvrhel_laptop: OK. Thanks | 17:05.53 |
| mvrhel_laptop | so, as I said it is on by default | 17:06.05 |
| | this way you can turn it off even for the separation devices | 17:06.19 |
| | so we can do what Acrobat pro does in the output preview window | 17:06.36 |
| rayjj | mvrhel_laptop: I don't think it is working. Try gswin32c -r90 -dSimulateOverprint=true tests_private/comparefiles/Altona_Visual_sb_1v1_x3.pdf | 17:11.02 |
| mvrhel_laptop | rayjj: ok hold on | 17:11.20 |
| rayjj | (with whatever path you have tests_private in | 17:11.27 |
| mvrhel_laptop | what am I going to be looking for/at | 17:11.50 |
| rayjj | I'm looking at the three circles on the top left of the lower right panel | 17:12.45 |
| | mvrhel_laptop: note the -dSimulateOverprint=true/false _does_ make a difference with -dDisplayFormat=16#20808 (CMYK mode) | 17:17.12 |
| mvrhel_laptop | hmm I do see a difference in RGB at page 9, which is odd | 17:18.02 |
| | rayjj: I am guessing you are looking at page 15? | 17:19.03 |
| | I don't see any diffs there | 17:19.10 |
| rayjj | mvrhel_laptop: as I said above, gs matches Acrobat 9 in CIE RGB mode for page 15 | 17:20.39 |
| mvrhel_laptop | oh yes it does | 17:21.09 |
| | with and without the simulate overprinting on/off i.e. AR shows no change in that case | 17:21.27 |
| | just like us ;) | 17:21.42 |
| rayjj | but page 7 has the left most D really faded, and on the Altona_Visual_sb_1v1_x3.pdf the "duotone" image grid is wrong as are the three circles that overlap | 17:22.01 |
| kens | OK night all | 17:22.51 |
| rayjj | mvrhel_laptop: with Edit/Preferences/OverPrint Preview: Never and Simulation Profile CIE RGB then the three circles are not "merged" on Altona_Visual_sb_1v1_x3.pdf | 17:24.32 |
| mvrhel_laptop | I don't have Altona_Visual_sb_1v1_x3.pdf handy | 17:25.06 |
| | need to grab it | 17:25.16 |
| rayjj | but the "grid" table on the 'duotone?' orange black is still the same for Adobe (and different to us) | 17:25.16 |
| mvrhel_laptop | do you mean Altona_Visual_bb_1v1_x3? | 17:25.42 |
| | rayjj: I see the three circles in Altona_Visual_bb_1v1_x3 | 17:27.27 |
| | in AR with an RGB profile they all overlap. No blending | 17:27.40 |
| rayjj | mvrhel_laptop: oh, wait a minute. There is OverPrint Preview: Never (on the menu path I mentioned above) and the "Simulate Overprint" on the Output Preview dialog. they each control different things | 17:27.43 |
| mvrhel_laptop | Yes. I dont use OverPrint Preview: Never | 17:28.08 |
| rayjj | un checking the Simulate Overprint makes the Acrobat output match gs for the duotone "grid" | 17:28.16 |
| mvrhel_laptop | I use the selection on the Output Preview | 17:28.17 |
| | right. just the gray is shown | 17:28.35 |
| | which is what mupdf does | 17:29.10 |
| rayjj | mvrhel_laptop: OK, so do you expect us to be able to do the equivalent of Acrobat Simulate Overprint in RGB mode on Altona_Visual_sb_1v1_x3.pdf ? (for the three circles _or_ the grid) ? | 17:31.10 |
| mvrhel_laptop | from what I am seeing AR does not really do all simulation of overprinting when in RGB output mode. It does some e.g. the orange and gray grid. But not the 3 circles | 17:31.20 |
| | let me see what we do then I will tell you what I expect us to do ;) | 17:31.50 |
| rayjj | mvrhel_laptop: agreed. That's what I see | 17:31.53 |
| mvrhel_laptop | I am hoping we do the same as AR | 17:32.05 |
| rayjj | mvrhel_laptop: well, we don't do the color grid | 17:32.37 |
| | I have to run an errand. bbiab | 17:33.05 |
| mvrhel_laptop | ok. we don't do the orange overprint | 17:34.10 |
| | I suspect that adobe is carrying around RGB + spots | 17:34.25 |
| | which allows them to overprint with spots | 17:34.35 |
| | but they don't fool with CMYK | 17:34.43 |
| | so, right now we don't have RGB overprinting that works | 17:35.14 |
| | and I suspect to do it, we will need to make a special type of compositor | 17:35.36 |
| | or extend the capabilities (and the cost/speed) of the overprint compositor | 17:36.02 |
| | basically a planar buffer to collect colorants. it would get ugly | 17:36.43 |
| | It would be better to just do a proper cmyk workflow.... | 17:36.59 |
| | ok. I will see if I can fix a few of ken's comments on gsview | 17:37.44 |
| | ok. finally figured out how to override the wpf listview selection background color issue | 17:46.33 |
| | ok. fixed the search so it is at the top and also so it gets the focus when first clicked | 18:04.54 |
| rayjj | mvrhel_laptop: It doesn't seem like getting the circles "right" would require extra planes, and "merging" tint-transform "orange" with shades of gray should be possible without extra planes. But then other things might break | 18:10.00 |
| | mvrhel_laptop: it seems like we don't even try to do anything with Overprint to an RGB device | 18:10.41 |
| mvrhel_laptop | rayjj: I am a little surprised. I swear I had it working at one point | 18:11.27 |
| | I was just in that part of the code. I will take a closer look today | 18:11.52 |
| Robin_Watts | Does anyone have a >4Gig PDF? | 18:12.59 |
| | even a >2Gig one would do at a pinch. | 18:13.11 |
| mvrhel_laptop | Robin_Watts: sorry not me. Where did that million pager go? | 18:15.04 |
| Robin_Watts | That was only 400Meg. | 18:15.14 |
| mvrhel_laptop | ah ok | 18:15.27 |
| | so how big should I make the page thumbnails.... Should I make it user configurable? | 18:15.48 |
| fredross-perry | Hi all. I *believe* that Iâve updated mupdf to use VER-2-5-5 or freetype, and pushed that to my mupdf repo. plz check me. ALso, I could use some instruction regarding how to do clusterpush/bmpcmp. Thanks. | 18:15.51 |
| Robin_Watts | fredross-perry: I can talk you through the cluster stuff. | 18:16.21 |
| fredross-perry | ok, thanks. Skype, or here? | 18:16.40 |
| Robin_Watts | here is fine. | 18:16.47 |
| fredross-perry | ok hit me. | 18:16.58 |
| Robin_Watts | Just give me a mo... | 18:16.59 |
| fredross-perry | NP | 18:17.03 |
| mvrhel_laptop | hmm zoom control does need a little work too. have to take a break for bit. bbiaw | 18:18.34 |
| Robin_Watts | fredross-perry: OK, so I believe you have a password so that you can see: http://ghostscript.com/regression ? | 18:19.45 |
| fredross-perry | mvrhel_laptop: FYI, in response to some gsview/mac feedback from Henry, I am now doing a thing where I attempt to initially show a just-opened doc at actual size, if it fits. Preview/Mac does this. | 18:19.57 |
| | Robin_Watts: yes | 18:20.24 |
| Robin_Watts | cool. | 18:20.30 |
| | So, there are 2 mechanisms for kicking off a cluster test. | 18:21.10 |
| | One is git based, and is generally used by the windows users. | 18:21.23 |
| | The other is rsync based and is generally used by the unixers. | 18:21.38 |
| | Let's try for the rsync based one first. | 18:21.56 |
| | Do you have a checkout of gs on your machine? | 18:22.05 |
| fredross-perry | this is mupdf, not gs | 18:22.16 |
| | but yes i do | 18:22.20 |
| Robin_Watts | I know. | 18:22.21 |
| | So in ghostpdl.git/gs/toolbin/localcluster there should be a clusterpush.pl file. | 18:22.49 |
| | That's the magic file. | 18:22.52 |
| fredross-perry | I see it | 18:23.10 |
| Robin_Watts | What is your local user name on your mac ? | 18:23.19 |
| fredross-perry | fredross-perry (I think) | 18:23.38 |
| Robin_Watts | OK, so your cluster username is 'fred'. | 18:23.50 |
| fredross-perry | ok | 18:24.01 |
| Robin_Watts | To cope with that do: export CLUSTER_USER=fred | 18:24.03 |
| | Then, open a terminal, and cd into the mupdf directory. | 18:24.40 |
| fredross-perry | yes | 18:24.41 |
| Robin_Watts | Then run clusterpush.pl | 18:24.46 |
| | Hopefully you'll see rsync run for a bit, and the job should be queued. | 18:25.19 |
| | actually, you might need to do: clusterpush.pl mupdf | 18:26.04 |
| fredross-perry | apparently I need a cluster_key file | 18:26.48 |
| Robin_Watts | ah, right, yes. hold on... | 18:26.57 |
| | You want to copy /home/regression/cluster_key on casper. | 18:27.37 |
| fredross-perry | stand by... | 18:27.52 |
| Robin_Watts | and you want to do that mac specific thing that you have to do with keys to get them into your keyring. | 18:28.03 |
| fredross-perry | yes | 18:30.32 |
| | hold on... | 18:30.39 |
| | syncing | 18:32.04 |
| | You're not allowed to run 'rsync --server -vlogDtprcxz --max-size 10000000 --delete-excluded . /home/regression/cluster/users/fred/mupdf' | 18:32.05 |
| | rsync: connection unexpectedly closed (0 bytes received so far) [sender] | 18:32.06 |
| | rsync error: error in rsync protocol data stream (code 12) at /SourceCache/rsync/rsync-45/rsync/io.c(453) [sender=2.6.9] | 18:32.08 |
| | queueing | 18:32.09 |
| | You're not allowed to run 'rsync --server -vlogDtprcxz . /home/regression/cluster/users/fred/mupdf' | 18:32.11 |
| | rsync: connection unexpectedly closed (0 bytes received so far) [sender] | 18:32.12 |
| | rsync error: error in rsync protocol data stream (code 12) at /SourceCache/rsync/rsync-45/rsync/io.c(453) [sender=2.6.9] | 18:32.12 |
| Robin_Watts | D'Oh. | 18:32.15 |
| | Sorry, that's security stuff on casper I have to update. | 18:32.25 |
| fredross-perry | okee | 18:32.37 |
| Robin_Watts | First I have to find it... | 18:34.29 |
| | fredross-perry: OK, try again now. | 18:46.02 |
| fredross-perry | seems to have done something. | 18:46.36 |
| Robin_Watts | Ok, so if you look at the web dashboard, you'll see your job running. | 18:47.19 |
| fredross-perry | job queue says I am running. | 18:47.22 |
| | how long does this part usually take? | 18:49.37 |
| Robin_Watts | fredross-perry: For MuPDF about 4 mins. | 18:54.16 |
| fredross-perry | looks done now. | 18:54.25 |
| Robin_Watts | There is a percentage shown in the top bar while the job is running. | 18:54.36 |
| | The percentage is of dispatched jobs, so it's a bit in advance of the actual completed jobs, but... | 18:54.56 |
| | So, now it's run, click on 'fred' under 'User links' | 18:55.06 |
| | ok, that's not working. hold on :) | 18:55.24 |
| fredross-perry | ok | 18:55.27 |
| | holding | 18:55.43 |
| | This is testing a copy of the code thatâs sitting on my machine, yes? As opposed to whatâs in any git repo. | 18:57.53 |
| Robin_Watts | It is. | 19:02.09 |
| | The first thing that happens is that your local dir gets rsynced up to a special place on casper, and that then gets rsynced around the cluster machines. | 19:02.45 |
| | OK, so it should work now. | 19:02.49 |
| | 8979 differences. | 19:03.05 |
| | So... clusterpush.pl bmpcmp | 19:03.49 |
| | fredross-perry ? | 19:07.06 |
| fredross-perry | yes? | 19:07.26 |
| Robin_Watts | Did you try: clusterpush.pl bmpcmp ? | 19:07.47 |
| fredross-perry | I suppose thatâs a lot of differences then. | 19:07.55 |
| Robin_Watts | fredross-perry: It is, but given it's a change in freetype it may not be more than expected. | 19:08.18 |
| fredross-perry | ok just queued up clusterpush.pl bmpcmp | 19:08.40 |
| Robin_Watts | ok, this will look at the first 1000 of the diffs. | 19:08.56 |
| fredross-perry | does each user get their own silo in regression-land? What I am testing wonât interfere with others? | 19:10.36 |
| Robin_Watts | exactly. | 19:10.49 |
| fredross-perry | cool. Now when I visit the dashboard, itâs blank. | 19:13.41 |
| Robin_Watts | The dashboard has stopped responding for me. | 19:14.01 |
| fredross-perry | requests for /regression/cgi-bin are getting cancelled. | 19:15.26 |
| | oh wait it just cme back. | 19:15.40 |
| Robin_Watts | ok, it's come back to life. | 19:15.44 |
| | no idea what happened there. | 19:15.47 |
| fredross-perry | says I am still running | 19:15.57 |
| | (bmpcmp) | 19:16.04 |
| Robin_Watts | yeah, so 1000/1000 jobs have been sent out. | 19:16.11 |
| | We're just waiting for the nodes to finish with the last jobs now. | 19:16.24 |
| | When they finish, they will send the results back. | 19:16.43 |
| | This can take longer than before as they have to transfer bitmaps, not just textual results. | 19:17.08 |
| fredross-perry | got it | 19:17.16 |
| Robin_Watts | Once all the bitmaps are in, a process then runs on casper to turn them into 'readable' displays with an HTML page. | 19:17.56 |
| | The progress of that process is not shown on the dashboard - it typically takes a minute or so. | 19:18.16 |
| | after that time, clicking on 'bmpcmp' to the right of 'fred' should take you to the report. | 19:18.47 |
| | fredross-perry: OK, so the results are there now. | 19:20.47 |
| fredross-perry | I am looking at some of them now. Interesting. How do we go about avaluating these? Clearly youâd hope for no differences. | 19:20.51 |
| Robin_Watts | fredross-perry: The left bitmap is the new one. the middle one the old, and the right one the diff. | 19:21.21 |
| | green pixels in the diff are 'small' differences, red pixels are 'big' differences. | 19:21.39 |
| fredross-perry | so this is interesting. Look at the first one. The tool seems tobe hilighting pixel differences in some of the letters. But by eye I canât see them in the left and middle pictures. | 19:22.26 |
| Robin_Watts | So, I've just looked at the first page, and all the differences are in text, as you'd expect. | 19:22.35 |
| | fredross-perry: Indeed, the text is antialiased, so the difference is probably just in the grey pixels. | 19:22.54 |
| | So, probably there is nothing here to worry about. | 19:23.31 |
| | There are some tricks we can try here... | 19:23.45 |
| fredross-perry | Mind you, this all started because I found a fix for a bug that was already fixe in a more recent version of FT. | 19:24.04 |
| Robin_Watts | If you hold the ctrl key down, then when you move your mouse pointer into the left hand bitmap, it will swap places with the middle bitmap. | 19:24.31 |
| | And when you move the mouse pointer out again, it will swap back. | 19:24.48 |
| | so by waggling the mouse, you can sometimes see pixels flick on and off. | 19:25.03 |
| | but in this case... not so much. | 19:25.13 |
| fredross-perry | so do we just scroll thru the diffs looking for red? | 19:25.42 |
| Robin_Watts | Well, there are a couple more tricks :) | 19:25.54 |
| | If you do: clusterpush.pl bmpcmp -t16 | 19:26.07 |
| | that will rerun the test and will exclude all the diffs where the value of a pixel differs by less than 16 | 19:26.33 |
| | might want to use 32 actually. | 19:26.53 |
| | t= threshold. | 19:27.13 |
| | and that's 32 out of 256, obviously. | 19:27.21 |
| fredross-perry | at a quick glance, this ALL looks like antialising differences. Iâll try t32 now | 19:27.34 |
| Robin_Watts | Yes. | 19:27.51 |
| fredross-perry | So Iâll leave it to yâall regarding how/when to adopt this change. There was one change to a file because they reorganized the freetype files somewhat. | 19:30.53 |
| | ⦠meaning a file NOT in freetype itself. | 19:31.15 |
| Robin_Watts | fredross-perry: Let's look at the bmpcmp differences. | 19:31.53 |
| | Presumably you have an example file that now works, where it previously didn't ? | 19:32.09 |
| | mvrhel_laptop: You use acrobat a lot, right? Can I load a PDF into it and save it out as a different version of acrobat? | 19:33.38 |
| mvrhel_laptop | you can save it optimized or pdf-x etc is that is what you mean | 19:34.24 |
| Robin_Watts | mvrhel_laptop: I want to load the 1 million page PDF in, and save it as an older version of the PDF, so it doesn't use object compression. | 19:34.50 |
| | hopefully that'll make it bigger :) | 19:35.00 |
| mvrhel_laptop | you can make it as Acrobat 1.3 | 19:35.41 |
| | if that is what you want | 19:35.46 |
| Robin_Watts | how? | 19:35.49 |
| | Using the 'Optimize' option? | 19:36.04 |
| mvrhel_laptop | Save As | 19:36.14 |
| Robin_Watts | (Trying it now, but it's taking ages). | 19:36.16 |
| mvrhel_laptop | the pick settings | 19:36.24 |
| Robin_Watts | Save As doesn't let me change the settings. | 19:36.26 |
| mvrhel_laptop | you don't see a settings button in the Save As window? | 19:37.05 |
| fredross-perry | yes, a file that fell into inf loop inside FT, which does not now. | 19:37.52 |
| Robin_Watts | yes, but it's greyed out. | 19:37.57 |
| | fredross-perry: Ah, ok. | 19:38.05 |
| mvrhel_laptop | select optimized | 19:38.45 |
| | for the pdf type | 19:38.47 |
| fredross-perry | Itâs from a set of files that the user had done some random corruptions to, producing various hangs and crashes. | 19:38.48 |
| mvrhel_laptop | Robin_Watts: | 19:38.49 |
| | ^^ | 19:39.06 |
| Robin_Watts | mvrhel_laptop: Select optimised where? | 19:39.16 |
| mvrhel_laptop | then is should not be grayed out | 19:39.16 |
| | in the Save As window | 19:39.22 |
| Robin_Watts | will try that as soon as I get control back. Thanks. | 19:39.36 |
| mvrhel_laptop | ok | 19:39.40 |
| | in the Save As Type: Selection | 19:39.51 |
| | You want Adobe PDF Files, Optimized. Then the Setting button will be enabled, where you will then be able to select 1.3 as the output | 19:40.24 |
| Robin_Watts | aha. | 19:40.24 |
| | fredross-perry: Look at page 4 of the results. | 19:40.33 |
| | test 436. | 19:40.43 |
| mvrhel_laptop | off to lunch now. then I will add a MRU list to gsview. | 19:41.02 |
| fredross-perry | Robin_Watts: hmmm.. | 19:41.28 |
| Robin_Watts | And 534 introduces some text that was missing. | 19:41.40 |
| fredross-perry | which side is the reference side again? | 19:41.47 |
| Robin_Watts | Candidate, Reference, Diff. | 19:42.13 |
| | Old, New, Diff | 19:42.21 |
| | 540 adds a , | 19:42.36 |
| fredross-perry | how can I get the reference files themselves? | 19:45.05 |
| Robin_Watts | The test files? | 19:45.28 |
| | Either you can checkout 250Gig of test files from SVN... | 19:45.48 |
| | or you can 1) click on the links in the bmpcmp. | 19:46.05 |
| fredross-perry | yes. Also, 539 is displaying abunch of text thatâs not in the reference. âBosnia (genocide)â for example. | 19:46.26 |
| Robin_Watts | 2) Click on the links in the report (when viewed on the web) | 19:46.48 |
| | 3) use the 'Fetch test files' link on the dashboard. | 19:47.07 |
| | Yeah, 539 is the same file as 534 (just at a different resolution/output/banding setting) | 19:47.34 |
| fredross-perry | re: 539, Preview does NOT show the extra text, but Adobe Reader (9) does, and now gsview with the updated FT does as well. | 19:49.32 |
| Robin_Watts | OK. Matching acrobat is generally considered good. | 19:52.29 |
| fredross-perry | 439 is sort of the reverse. Preview, Adobe and gsview do not show anything. Adobe issues an error message. gsview logs this: warning: freetype load glyph (gid 1): broken file | 19:53.30 |
| | warning: freetype load glyph (gid 1): broken file | 19:53.31 |
| | warning: ... repeated 2 times ... | 19:53.32 |
| | warning: cannot render glyph | 19:53.33 |
| Robin_Watts | so we (now) don't render the glyph, and neither do any of the others? | 19:54.51 |
| | again, that sounds like we're all agreeing now. | 19:55.32 |
| fredross-perry | sounds that way. At least on Mac. So ,was FT wrong to render it before? | 19:56.29 |
| Robin_Watts | possibly, yes. | 19:56.40 |
| | So, just 540 and co to look at. | 19:59.55 |
| fredross-perry | then there is 543. seemingly-random commas abound. New FT shows them, ref does no, Preview does, Adobe does not. Hmmm | 20:01.28 |
| | Does Adobe use FT? | 20:02.30 |
| Robin_Watts | no. | 20:02.52 |
| | How about gs? | 20:04.13 |
| fredross-perry | what do you mean âHow about gsâ? | 20:06.29 |
| | are you saying âletâs update gs to the latest FT and regression-test thatâ? | 20:07.21 |
| Robin_Watts | I mean, how does gs render 543 ? | 20:10.24 |
| | I'd be tempted to do: clusterpush.pl mupdf -filter=ppmraw.200.1 | 20:11.44 |
| | That will rerun the tests, but only test the ppmraw device with banding at 200 dpi. | 20:12.05 |
| | Hopefully you'll find you have fewer differences. | 20:12.22 |
| | Then you can run: clusterpush.pl bmpcmp | 20:12.34 |
| | oops. I mean: clusterpush.pl bmpcmp -t32 | 20:13.07 |
| | That way, when it tests the first 1000 differences, we'll get a higher proportion of them actually tested. | 20:13.33 |
| | I've got to step away from the keyboard now (Helen is calling me). | 20:13.53 |
| | let me know what you find, and we'll discuss it with tor tomorrow. | 20:14.08 |
| | I suspect we'll just take the new version. | 20:14.15 |
| fredross-perry | (1) do you mean how does gs render 543 with the latest FT,? I am stepping out as well. | 20:14.23 |
| MacWinner | hi, is it possible to use mupdf to input a broken pdf and then output a repaired one? i noticed mudraw is able to render a PDF into images fine even if there is a screwed up xref table.. I was hoping to also be able to output a fixed PDF as well | 20:22.55 |
| | just mutool clean maybe? | 20:23.46 |
| | oh.. looks like it worked! | 20:24.56 |
| | Forward 1 day (to 2015/03/17)>>> | |
IRC Logs