| | <<<Back 1 day (to 2011/12/07) | 2011/12/08 |
| Robin_Watts | sebras, tor8: Everything I've fixed on master, I've done simultaneously on context. | 00:12.29 |
| kens | Hey chrisl, I see Debashis Sahoo is at it again 'we want a fix for an ancient version of Ghostscript'..... | 08:06.32 |
| chrisl | kens: yes, I think I'm going to drop a mail to Miles and ask his advice on it - given the customer in question.... | 08:11.47 |
| kens | I'd just say 'no' personally. | 08:12.08 |
| chrisl | Have we done so before? | 08:12.21 |
| kens | We've done that on other bugs they've reported | 08:12.24 |
| | Yes, recently. | 08:12.29 |
| | We don't offer support on versions prior to 9.0 now. | 08:12.40 |
| chrisl | Oh, right, no need to bother Miles then...... | 08:12.44 |
| kens | 8.71 predates my joiining Artifex I think. | 08:12.56 |
| chrisl | No, it pre-dates my joining by about 4 months | 08:13.22 |
| kens | Yes, so I see, I must have been thinking 8.61 | 08:13.37 |
| chrisl | Or one of the other random, ancient versions that people keep popping up with! | 08:14.05 |
| kens | But anyway, we support versions until 12 months after they are superceded | 08:14.07 |
| chrisl | There, terse and to the point..... | 08:15.14 |
| kens | :-) | 08:15.21 |
| | I'd also point out its a font issue, the last one we said 'no' to wa a font issue that was fixed by using FreeType, so they *need* to upgrade | 08:15.51 |
| chrisl | I think, given this has been explained to them at least twice that I can see now, I prefer the terse approach this time! | 08:16.51 |
| kens | I'm not complaining ;-) | 08:17.03 |
| chrisl | I found the problem with that overly bold text issue you punted my way...... | 08:17.16 |
| kens | Well I figured it was your area, not mine any more | 08:17.34 |
| chrisl | It's actually got nothing to do with transparency either! | 08:17.50 |
| kens | Now that does surprise me | 08:18.03 |
| chrisl | Most of the glyphs are tr 0, but the extra bold ones are tr 7 then an image rendered through the clip | 08:18.31 |
| kens | Yeah, a stupid way to do it. | 08:18.54 |
| chrisl | The problem is that glyphs are filled with fill_adjust set to 0, but the clip is set with the default fill_adjust, so end up "bolder" | 08:19.17 |
| kens | Well its basiclaly what I said, except that being Tr7 its is 'sort of' text. | 08:19.48 |
| chrisl | I'm hoping I can fix it in the PDF interpreter | 08:20.05 |
| kens | clip+image != rendered text | 08:20.22 |
| chrisl | No, but the are of the clip really ought to be the same as the area covered by a fill | 08:20.55 |
| | s/are/area | 08:21.01 |
| kens | Yes, I guess so. | 08:21.29 |
| chrisl | That's what it says in the spec..... I would expect minor shape differences, but the overall area ought to be about the same | 08:22.14 |
| kens | I can tell you where to find the code in the PDF interpreter I think. | 08:22.42 |
| | Its complicated. | 08:22.49 |
| chrisl | I'm already testing the fix, but thanks :-) | 08:22.59 |
| kens | Ah, OK | 08:23.04 |
| | You are limiting it to the 'non-pdfwrite' cases ? | 08:23.26 |
| chrisl | I don't think so, but pdfwrite shouldn't be affect by fill_adjust changes, should it? | 08:24.05 |
| kens | I'm not sure. My initial thought was that it should be immune, but then I recosidered. | 08:24.31 |
| | I guess we'll see what comes out of the regression test | 08:25.03 |
| chrisl | Well, pdfwrite should normally grab paths before they are scan converted. In cases where it doesn't, it will want the correctly scan converted data, so it should be fine | 08:32.09 |
| | kens: did Ray ever raise a bug or contact you about the pdfwrite/FAPI problem? | 08:41.06 |
| kens | Which problem ? | 08:49.18 |
| chrisl | The one where FAPI is rendering the glyph despite pdfwrite being the device | 08:50.44 |
| kens | Oh, no he didn't, I'd forgotten about that. | 08:50.57 |
| chrisl | It stems from Bug 692674 | 08:51.54 |
| kens | Which is rapidly griwing, what with colours and stuff. | 08:52.38 |
| | growing | 08:52.44 |
| | I'll send Ray a reminder now. | 08:52.52 |
| | Actually, maybe I don't need input from Ray, unless he has a simplified file ? | 08:53.45 |
| chrisl | It doesn't get much simpler than the file they supplied - it's just a page of text from a type 1 font, IIRC | 08:54.16 |
| kens | OK, then I can look at that. After I finish figuring out Till's problem. | 08:54.36 |
| chrisl | It probably should have a bug of its own. | 08:55.25 |
| kens | I think it should, since this one is disappearing off into colour | 08:55.49 |
| | Anyway, I have the file now. | 08:56.09 |
| chrisl | Let me know if you need any FAPI reminders | 08:56.54 |
| kens | I'm in there now looking at Till's issue :-( | 08:57.16 |
| | Trying to figure out why <0A> comes out as character code 0x05 in FAPI | 08:57.43 |
| chrisl | Eh? That's ps2write isn't it? | 08:57.44 |
| kens | Yes. | 08:57.50 |
| chrisl | What's the font type? | 08:58.03 |
| kens | TrueType converted to type 42 by the opdfread header | 08:58.17 |
| | Wow, FAPI_do_char is getting pretty big and complex | 08:59.12 |
| chrisl | So, from the cmap table mapping maybe? | 08:59.13 |
| kens | Yes, could be, I'm just trying to prove it before I go decoding the font. | 08:59.30 |
| chrisl | Well, give me a yell if you want some input - oh, but I'm going to be out for a few hours from about 10 this morning - I have to try to de-malware my parent's computer | 09:00.08 |
| kens | Oh, what fun :-( | 09:00.21 |
| | I've been here recently (Till's last 2 problems) so I'm probably OK, still feeling my way through the issue. | 09:00.52 |
| | OK character code is 0x0A in FAPI_do_char | 09:01.45 |
| | Looks like its the Encoding | 09:01.56 |
| | Which is built on the fly from the CMAP I think. I'm not actually sure its incorrect.... | 09:02.49 |
| | Time to decode the font. | 09:02.53 |
| | Well, CMAP looks OK 2 characters, 0x03->GID 0x04, 0x0A-> GID 0x05 which matches what I see in FAPI | 09:07.47 |
| | LOCA table has offsets for GID 0, 4, 5 and 15 (nto sure why 15) | 09:08.56 |
| | Oh, glyph 4 is a composite. | 09:09.32 |
| | Which I think uses glyph 5. Looks like the CMAP may be wrong. | 09:09.52 |
| | Yes, if I substitute character code 15 for 5 then I get the correct result. | 09:14.19 |
| | The CMAP subtable in the TrueType font is incorrect. | 09:14.40 |
| chrisl | So is that a result of the stuff that opdfread does, or is it the TTF emitted by ps2write/pdfwrite that's wrong? | 09:18.07 |
| kens | Its the TrueType font embedded in the output PostScript, so its ps2write at fault | 09:18.27 |
| | Its fine until I add the compostie glyph, so its somethgin weird with teh composite glyph (again) | 09:18.45 |
| chrisl | Well, at least that's probably easier to debug than the horrific opdfread Poststscript | 09:19.15 |
| kens | I certainly hope so! | 09:19.24 |
| | I'm not convinced the 'composite' glyph is actually a composite, it only seems to have one component. | 09:19.49 |
| | But that's a different issue ;-) | 09:20.02 |
| tkamppeter | kens, hi | 09:20.21 |
| kens | Hi Tkamppeter | 09:20.26 |
| tkamppeter | kens, did you already have a look into bug 692716 and bug 692711? | 09:20.58 |
| kens | The conversation above is all to do with #692711 | 09:21.11 |
| | #692716 'looks' like its the same problem, but I won't know for sure till I try it. | 09:21.35 |
| | To summarise #692711; the TrueType font in the emitted PostScritp stream has an incorrect CMAP when (and only when) we use the 'composite' glyph corresponding to the 'a' glyph. | 09:22.40 |
| | I'm about to start debugging the CMAP generation | 09:23.02 |
| | FWIW I have reduced the sample file to two glyphs which makes it easier to work with. | 09:23.28 |
| | By the way tkamppeter, I *strongly* recommend you adopt commit '979f2182372d924ce69f8d904e87173107209b6b' as well if you are doing a patch. | 09:25.48 |
| tkamppeter | kens, thanks for this hint, simple patch with high positive impact. Can you give me a sample file where one can easily see the improvement/fix? | 09:37.49 |
| kens | Hmm, it was a bug report, just a moment. | 09:38.09 |
| | tkamppeter the file attached to bug #692612 should show the problem. | 09:41.13 |
| tkamppeter | kens, what I observe is that when passing the file through ps2ps2 (the Linux shell script version) the resulting PS file has a fine black line around the image, GS 9.04 is not erroring out on the conversion. Is this the problem of this bug? | 09:48.35 |
| kens | Yes, that's correct | 09:48.46 |
| | THe final step of the image shuld be white, but is actually black | 09:49.01 |
| tkamppeter | kens, so I will make a Ubuntu report and slip the fix in with the Oneiric update for the other two bugs. | 09:49.43 |
| kens | It doesn't cause an error, just incorrect output. If you want to see other examples, the files that show differences in our test suite are listed in the commit. Any of those with a 'Bug' prefix should be available for you to look at if you want. | 09:49.58 |
| | tkamppeter, that sounds like a good idea. | 09:50.12 |
| | Still looking at the other bugs. | 09:50.21 |
| chrisl | Right, off to fix a computer - back.... well, at some point :-( | 09:58.22 |
| kens | Have fun.... | 09:58.29 |
| chrisl | Hmm, thanks - I guess..... | 09:59.06 |
| ja | hi, can u help me with a ps2pdf error, I pasted it here http://pastebin.com/zT21iAtf. pdflatex produces correct pdf file, but its size is too big | 10:35.36 |
| kens | That's an interpretation error, so it suggests the original is invalid. | 10:36.13 |
| | You should open a bug report at http://bugs.ghostscript.com and attach the source PostScript or PDF file. | 10:36.41 |
| ja | do you mean .tex file is broken, or .ps? | 10:37.04 |
| kens | Ghostscript dos not accept .tex as an input. So it must be the PostScript file. | 10:37.28 |
| | You might also try the current version of Ghostscritp which is 9.04 insted of 9.00 | 10:37.42 |
| ja | ok, i'll give it a try | 10:38.35 |
| Robin_Watts | tor8: ping | 11:49.16 |
| tor8 | Robin_Watts: pong. | 11:50.04 |
| Robin_Watts | No roundf on MSVC | 11:50.14 |
| | Any objection to me replacing roundf(x) with (int)((x) + 0.5) ? | 11:50.51 |
| tor8 | make it + 0.5f so you don't get implicit double precision math and I'm fine with it | 11:51.42 |
| Robin_Watts | fab. | 11:51.48 |
| | I plan to put your 3 patches on master, and then merge down to context, OK ? | 11:52.03 |
| tor8 | okay. | 11:52.13 |
| | I made them on master so :) | 11:52.17 |
| Robin_Watts | My master will end up different to yours then, cos I'm going to fix the roundf thing. | 11:52.49 |
| | Or do you want to fix it, then push it, and I'll pull it, and merge to context ? | 11:53.10 |
| | (I'd rebase -i HEAD~4 to pull the offending commit to the top of the history, then git commit --amend it, then rebase -i HEAD~4 to push it back down again) | 11:54.24 |
| tor8 | I'll pull whatever you do | 11:55.03 |
| | I haven't pushed yet so it's no prob | 11:55.13 |
| | I'm banging on the x11_main.c so I can get the context branch through sane | 11:55.29 |
| | which is running now. I'll let you know the results in a min. | 11:55.59 |
| | Robin_Watts: heh, we get a funny mix of old-style fz_throw-backtraces and "error:" messages now | 12:00.16 |
| | we get plenty of segfaults in what I believe is the repairing code now | 12:02.47 |
| Robin_Watts | Damn. Want to point me at a file? | 12:05.47 |
| tor8 | have you got the sane database? | 12:06.05 |
| Robin_Watts | on the macbook, yes. | 12:06.27 |
| tor8 | x - SumatraPDF1.1DOS.pdf | 12:07.03 |
| Robin_Watts | I don't have that one. | 12:10.30 |
| | I only have 10 files. | 12:10.39 |
| tor8 | Robin_Watts: casper:/home/tor/test.tar (55Mb) | 12:13.58 |
| Robin_Watts | tor8: Thanks, I'll grab that, but I'd better grab the single file first. | 12:18.20 |
| | broadband stuff S L O W | 12:18.26 |
| tor8 | untar it on casper and get what you need :) | 12:18.47 |
| | I should look into some git-based test archive system | 12:19.22 |
| Robin_Watts | Won't that result in 2 copies of the checkouts on every machine ? | 12:20.00 |
| tor8 | that's what I need to look into | 12:20.57 |
| Robin_Watts | win32/Debug/pdfdraw.exe -o out.png ../MyTests/sane/x\ -\ SumatraPDF1.1DOS.pdf 1 | 12:25.23 |
| | That completes with no SEGV for me. | 12:25.30 |
| sebras | tor8 Robin_Watts: even if thailand has been flooded isn't disk still cheap? | 12:26.54 |
| Robin_Watts | sebras: Depends on whether you're talking about wasting 55Meg or 500Gig :) | 12:28.12 |
| sebras | Robin_Watss: true, but my entire archive is only 5Gb... | 12:30.14 |
| tor8 | Robin_Watts: segfaults for me in pdf_repair_xref / fz_malloc_array / fz_malloc_default / ... malloc_consolidate | 12:30.38 |
| Robin_Watts | 5Gb is a lot to waste on an SSD (and that's what tor8 has) | 12:30.43 |
| | tor8: debug or release build ? | 12:30.56 |
| tor8 | probably memory corruption, let me run valgrind | 12:31.04 |
| | Robin_Watts: both | 12:31.08 |
| Robin_Watts | memento :) | 12:31.26 |
| sebras | Robin_Watts: sure, I'll just convince him to uninstall a game and he'll have more than enough space unused. | 12:31.33 |
| tor8 | ==10678== Invalid read of size 4 | 12:31.42 |
| | ==10678== at 0x8498446: fz_drop_obj (base_object.c:839) | 12:31.42 |
| | ==10678== by 0x8055794: pdf_parse_array (pdf_parse.c:297) | 12:31.43 |
| | looks like a refcount error... it's in the fz_catch in pdf_parse.c:297 | 12:33.00 |
| Robin_Watts | The default case should probably not fz_drop_obj(ary); | 12:34.05 |
| | line 288 | 12:34.13 |
| tor8 | yeah | 12:34.20 |
| | Robin_Watts: that solves the segfault | 12:35.13 |
| Robin_Watts | fab. | 12:35.19 |
| | Fixed, and pushed. | 12:36.42 |
| | I've forgotten to extend the VS solution to do Memento builds. Will do that now. | 12:37.21 |
| tor8 | Robin_Watts: "1172 - strange bookmark.pdf" has another segfault. it's trying to resolve an indirect reference while repairing... | 12:41.25 |
| | pdf_repair.c:67: | 12:41.54 |
| | should probably read if (!fz_is_indirect(obj) && fz_is_int(obj)) | 12:42.48 |
| | or guard for null xref in pdf_resolve_indirect | 12:44.40 |
| | the second is probably the better way | 12:44.55 |
| Robin_Watts | yeah. | 12:45.06 |
| | Hmm. I don't see that line. | 12:45.55 |
| tor8 | it says if (fz_is_int(obj)) now | 12:46.10 |
| | but since it was an indirect reference, it tried to resolve it by going into the xref (which is NULL for objects parsed during repair) | 12:46.37 |
| Robin_Watts | So move line 1006 of pdf_xref.c inside the if (xref) ? | 12:47.45 |
| | fz_context *ctx = xref->ctx; | 12:47.57 |
| tor8 | http://ghostscript.com/~tor/stuff/resolve.diff | 12:47.59 |
| | d'oh forget that patch | 12:48.19 |
| | just move the if (xref) up :) | 12:48.25 |
| Robin_Watts | OK. Done. | 12:48.55 |
| | and pushed | 12:50.24 |
| | So... why isn't memento working. It's being predefined etc... | 12:50.44 |
| | because I'm a fool that's calling the debug version, not the memento version in the debugger :) | 12:53.25 |
| tor8 | hehe :) | 12:53.56 |
| | another issue, the "ignoring the rest of the file" case doesn't seem to be working on the context branch | 12:54.18 |
| | file '719 - EOF incorrectly detected.pdf' | 12:54.42 |
| Robin_Watts | So... why are changes to the solution not showing up in git diff... | 12:57.48 |
| tor8 | another segfault in 1439 - color softmask fails to draw jpx image.pdf (error: softmask must be grayscale followed by segfault) | 12:58.19 |
| Robin_Watts | I have MSVC. Maybe I'd already done Memento... | 13:00.00 |
| tor8 | file '0 - password password (crypt level 5).pdf' generates a lot more error messages since it doesn't trigger the 'invalid password' | 13:00.21 |
| | graphics wise, there are a few diffs in pdfref17.pdf (page 1149, one of the ducks has a missing backdrop, blend mode difference? page 1150 the gradients are a pixel or two bigger) | 13:02.08 |
| | and 'x - streamed structure causes stack overflow.pdf' has gone from segfault on master to 'exception stack overflow' on context :D | 13:02.51 |
| | that's all I can find with sane | 13:02.57 |
| Robin_Watts | Looking at the 719 file now. | 13:06.46 |
| | what's the problem? I get lots of "warning: ignoring invalid character in hex string" | 13:07.22 |
| | then: | 13:07.34 |
| | error: lexical error (unexpected ')') | 13:07.51 |
| | error: cannot load document '../MyTests/sane/719 - EOF incorrectly detected.pdf' | 13:07.53 |
| | | cannot open document: ../MyTests/sane/719 - EOF incorrectly detected.pdf | 13:07.55 |
| | \ aborting | 13:07.57 |
| tor8 | yeah. and on master it thows a lexical error, followed by fz_catch("ignoring the rest of the file") | 13:09.00 |
| Robin_Watts | What's the difference in the end (other than the different message?) | 13:10.26 |
| tor8 | the aborting means the file doesn't render anything | 13:10.48 |
| | whereas we get a page out (since the file just had garbage at the end) | 13:11.03 |
| | on master | 13:11.07 |
| | I think a bug fix must have gotten lost in a merge somewhere? | 13:11.37 |
| Robin_Watts | pdf_repair.c: line 251 | 13:12.02 |
| | Various places I didn't propogate the errors - but I noted them. | 13:12.21 |
| tor8 | ah, yes: "RJW: ignoring the rest of the file" | 13:12.57 |
| | I think that one is a mistake, it was a fz_catch where the other such notes were fz_rethrows | 13:13.49 |
| Robin_Watts | @@ -247,8 +247,15 @@ pdf_repair_xref(pdf_xref *xref, char *buf, int bufsize) | 13:14.41 |
| | if (tmpofs < 0) | 13:14.43 |
| | fz_throw(ctx, "cannot tell in file"); | 13:14.45 |
| | - tok = pdf_lex(xref->file, buf, bufsize, &n); | 13:14.47 |
| | - /* RJW: "ignoring the rest of the file" */ | 13:14.49 |
| | + fz_try(ctx) | 13:14.50 |
| | + { | 13:14.52 |
| | + tok = pdf_lex(xref->file, buf, bufsize, &n); | 13:14.53 |
| | + } | 13:14.54 |
| | + fz_catch(ctx) | 13:14.56 |
| | + { | 13:14.57 |
| | + fz_warn(ctx, "ignoring the rest of the file"); | 13:14.59 |
| | + tok = PDF_TOK_ERROR; | 13:15.01 |
| | + } | 13:15.02 |
| | if (tok == PDF_TOK_INT) | 13:15.04 |
| | { | 13:15.05 |
| | Seems to do the trick. | 13:15.07 |
| tor8 | actually, that doesn't do what it advertises | 13:15.43 |
| | the old version broke out of the loop | 13:15.48 |
| | this one skips the garbage | 13:15.54 |
| Robin_Watts | I could do 'break;' instead of tok=PDF_TOK_ERROR; | 13:16.41 |
| | That also gets me output. | 13:17.46 |
| | OK. Fixed and pushed. | 13:20.50 |
| | 1439 now. | 13:21.17 |
| | I think I've missed a rethrow | 13:27.57 |
| | 1439 fixed and pushed. | 13:43.53 |
| | tor8: looking at 0 - password password now. | 13:48.30 |
| tor8 | Robin_Watts: how do you feel about passing NULL to mean &fz_default_allocator to fz_new_context()? | 13:50.15 |
| Robin_Watts | tor8: It wouldn't mortally offend me. | 13:51.30 |
| tor8 | it saves us a visible global and I think windows dll:s have problems with globals across dll barriers | 13:51.47 |
| Robin_Watts | It means that we'd ALWAYS require malloc etc, even in places where we don't ever use it. | 13:52.16 |
| tor8 | I know sumatrapdf did some voodoo to get around the fz_device_rgb colorspace globals | 13:52.32 |
| | you mean we'd link to malloc even though we never call it? | 13:52.51 |
| Robin_Watts | tor8: yes. | 13:52.59 |
| tor8 | right. | 13:53.02 |
| | if someone cares that much, they can always nuke the default allocator in the source... | 13:53.23 |
| Robin_Watts | If we ever meet an embedded system where it's a problem... yeah | 13:53.32 |
| tor8 | or we can shuffle the source around so the mallocs end up in their own .o file which can be skipped by the linker | 13:53.54 |
| Robin_Watts | tor8: No, we'd still presumably have: if (blah == NULL) blah = &fz_default_alloc; | 13:55.12 |
| tor8 | oh. yeah. | 13:55.23 |
| Robin_Watts | it's not a huge problem. | 13:55.32 |
| | The 'no globals across a DLL' sounds like a bigger one. | 13:55.48 |
| | Although that can be solved by: fz_get_default_malloc(); | 13:56.15 |
| | fz_new_context(fz_get_default_alloc()); | 13:56.37 |
| tor8 | trying to cut down on the boiler plate required here :) | 13:57.05 |
| Robin_Watts | Yeah, I understand. NULL seems reasonable to me. | 13:57.17 |
| | So is the 0 - password password thing something I've broken ? | 13:57.47 |
| tor8 | in master pdf_open_xref_with_stream throws an 'invalid password' error | 13:58.33 |
| | whereas on context we get a torrent of 'invalid string length for aes encryption' errors | 13:58.57 |
| Robin_Watts | yeah, I see the cockup now. | 14:05.06 |
| tor8 | Robin_Watts: looking into the remaining fz_error_note/make/handle now | 14:07.45 |
| | there's a handful left in the filters | 14:07.52 |
| | want me to turn those into exceptions? | 14:08.03 |
| Robin_Watts | Up to you. | 14:08.33 |
| tor8 | then I'll do it | 14:08.42 |
| | it also means that read won't return -1 for errors, it'll throw instead. | 14:08.59 |
| Robin_Watts | ok. | 14:09.08 |
| | Do you still prefer volatile to fz_var ? | 14:09.28 |
| | even though we get umpteen warnings we can't work around with volatile ? | 14:09.50 |
| tor8 | I think we should go with fz_var now that I've seen how it looks | 14:10.45 |
| Robin_Watts | Woo Hoo! :) | 14:11.02 |
| tor8 | :D | 14:11.12 |
| Robin_Watts | OK. fz_var changeover done. | 14:29.23 |
| | I'm going to get some lunch. hadn't realised the time. back in a bit. | 14:30.08 |
| | back. | 15:02.24 |
| kens | wishes chrisl would come back | 15:05.53 |
| Robin_Watts | tor8: pdfdraw leaks a bit. It looks like (at least some of) it is due to the use of 'die'. | 15:07.46 |
| | I am tempted to make those throw errors and catch them properly, but that will probably conflict with what you're doing, so I'll wait. | 15:08.21 |
| kens | is amused by this: | 15:10.13 |
| | http://www.theregister.co.uk/2011/12/08/palm_os_iphone/ | 15:10.13 |
| chrisl | kens: wish granted....... | 15:21.25 |
| kens | Aha, a chrisl | 15:21.26 |
| | chrisl my problem seems to be an Encoding issue in the original TrueType font as dumped from the PDF interpreter | 15:21.48 |
| chrisl | A cmap table problem | 15:22.19 |
| kens | character code is 0x0a, GID is 0.f, but the Encoding returned by encode_char is 0x05, which conflicts with the composite glyph. | 15:22.27 |
| | Any ideas where the Encoding comes from ? | 15:22.47 |
| | BTW did you fix your parents' PC ? | 15:23.10 |
| chrisl | I *think* I fixed it, but it seemed almost too easy...... | 15:23.41 |
| kens | Well, sometimes htey are... | 15:23.50 |
| Robin_Watts | tor8: I understand why the fix I gave Raed for the tiling thing wasn't working for him. | 15:24.07 |
| | He needs to take on another patch too. | 15:24.15 |
| | (i.e. the fix is correct for head). | 15:24.36 |
| chrisl | kens: It seemed to be just a couple of executables added to the Start menu to start automatically | 15:24.46 |
| kens | Sounds like a script kiddie kind of malware | 15:25.02 |
| Robin_Watts | But after Miles' email this morning, I think I'd better not tell him until we hear different. | 15:25.02 |
| chrisl | Probably. I could see how it would be frightening for some people - it locked out the GUI, with a message about police investigations and "pay this fine" to get your PC back..... | 15:26.11 |
| kens | Oh, ransomeware, and trivial stuff at that... | 15:26.32 |
| chrisl | Yeh, my only worry is if there was something better hidden as well, but I couldn't see anything | 15:27.05 |
| tor8 | Robin_Watts: yeah, we should probably just let him enter bugs into bugzilla and we'll fix them when we get around to it | 15:27.06 |
| kens | chrisl I don't think they usually bother with mulitple levels. | 15:27.24 |
| chrisl | Fingers crossed! | 15:27.35 |
| | kens: so, where are the problems with the Encoding coming up? | 15:27.53 |
| kens | Well, its pdfwrite/ps2write | 15:28.05 |
| | I'll try and explain | 15:28.09 |
| Robin_Watts | tor8: Did you see my previous comments (search for 'die' if you didn't) | 15:28.23 |
| kens | I have two glyphs, one is regular the other is composite (but has only one component!) | 15:28.29 |
| tor8 | Robin_Watts: yes. I haven't touched that file yet, but I was about to :) | 15:28.40 |
| Robin_Watts | ok, I'll let you go for it. | 15:28.50 |
| tor8 | you go ahead and fix the apps if you want, I can take care of the remaining xps errors. | 15:29.02 |
| Robin_Watts | OK. | 15:29.28 |
| kens | The original TT font (in the PDF file) has the first glyph as character code 0x0a, mapping to GID 0x0f through the CMAP. The second glyph is character code 0x03 mapping to GID 0x04 with additional compostie glyph GID=0x05 | 15:29.33 |
| | The way we re-assemble TT fonts is arcane. But basically we put the character code through the encoding to get the encoding position and figure out the GID. THis allows us to regenerate the CMAP. | 15:30.21 |
| | The composite glyph has to be added separately. | 15:30.30 |
| | The problem is that the Encoding attached to the TT font says that character code 0x0a (GID=0x0f) is encoded at position 5. When we put the composite glyph in at position 5 (we have no other choice, its not Encoded) it effectively overwrites the original glyph. | 15:31.38 |
| | What I don't understand is why the Encoding array has character code 0x0a at index 5 | 15:32.06 |
| chrisl | Okay, so this is all dealing with the original TTF font in the source PDF | 15:32.12 |
| kens | Yes. | 15:32.16 |
| | THe latter part is my problem (rebuilding the CMAP) | 15:32.25 |
| | If the Encoding returned 0x0f (which is what I would expect) then it would alll work | 15:32.39 |
| | I'm just trying a simplified file with only the 0x0a glyph to see if the ENcoding returns a different answer | 15:33.11 |
| | And it doesn't, its still returns 0x05 | 15:33.36 |
| chrisl | Does the PDF have an Encoding for the font? | 15:33.47 |
| kens | Not sure, just a moment | 15:33.56 |
| | No, it doesn't | 15:34.30 |
| chrisl | okay, well when loading a *normal* TTF (from disk), it looks like we create an encoding in gs_ttf.ps in the procedure ".charkeys" | 15:35.41 |
| kens | By the way, the font stream is weird, instead of beginning with teh usual version number it starts with 'true' | 15:35.44 |
| | Right, I bet that's where the problem arises. | 15:35.54 |
| | Now I have to go and figure that one out, thanks. | 15:36.13 |
| chrisl | I think "true" is a valid "magic number" for TTFs | 15:36.15 |
| kens | Doesn't work for ttfdump ;-) | 15:36.27 |
| chrisl | Well, maybe "TRUE", then? | 15:36.48 |
| kens | Nah, I just replaced it with the usual version number and it was happy | 15:37.13 |
| chrisl | Okay, loading from a TTF also uses ".charkeys" | 15:38.58 |
| | Does the font have a post table? | 15:39.08 |
| kens | Yes, but no POST names | 15:39.17 |
| henrys | hope you guys had a good flight I'm catching up with email and irc. | 15:39.30 |
| kens | We were good thanks henrys, it'll take you a while to catch up ;-) | 15:39.44 |
| | chrisl I'll send you the reduced file, saves to and fro'ing | 15:39.58 |
| | OK gone | 15:40.35 |
| chrisl | Wow, gmail is actually playing nice today :-) | 15:41.33 |
| kens | :-) | 15:41.40 |
| | chrisl ran it with TTFDEBUG and PDFDEBUG | 15:44.07 |
| | Says some stuff about extending MacRomanEncoding | 15:44.23 |
| chrisl | I'm just looking at the TTFDEBUG output | 15:44.23 |
| kens | .charkeys does some other stuff if PDFDEBUG is true | 15:44.52 |
| | But I don't think this code is going through there | 15:45.19 |
| | Does not print 'glyphencoding: length=' | 15:45.35 |
| chrisl | No, you're right | 15:46.15 |
| | .pdfcharkeys then | 15:47.03 |
| kens | :-) | 15:47.08 |
| | OK that looks complicated | 15:47.37 |
| chrisl | It's not nice :-( | 15:48.05 |
| kens | Looks like its going through the 'symbolic' section | 15:49.17 |
| chrisl | Yes, it finds a 1.0 cmap, and elects to use that | 15:49.40 |
| Robin_Watts | tor8: We appear to have lost fz_caught() somewhere along the line | 15:49.51 |
| kens | Flags are 4, I *think* that makes it symbolic | 15:49.55 |
| tor8 | yeah. where do you need it? | 15:50.14 |
| chrisl | kens: That's right, and amazingly it doesn't have an encoding! | 15:50.22 |
| kens | :-) | 15:50.28 |
| Robin_Watts | At the moment, we have the code printing to stderr on a throw. | 15:50.32 |
| | Ideally we shouldn't print on the throw, we should print when we handle it. | 15:50.49 |
| chrisl | kens: so, .pdfmapsymbolic is where the encoding comes from | 15:51.01 |
| kens | Seems to be, trying to figure that one out now | 15:51.11 |
| Robin_Watts | That way, if we catch an error and handle it nicely (perhaps by freeing some memory and trying again) we don't pollute stdout. | 15:51.18 |
| | (or stderr, rather) | 15:51.25 |
| tor8 | Robin_Watts: right. and here I was thinking about how to add an automatic stack trace on the fz_throw | 15:51.33 |
| | I don't really mind polluting stderr | 15:51.48 |
| Robin_Watts | tor8: Well, for a debug build that would be fine. | 15:51.53 |
| kens | OK hte output of the CMAp is upside down. | 15:53.37 |
| | Each pair is a character code and a GID starting at the top glyph and working down to 0. | 15:54.00 |
| | So the last entry is 0 0 | 15:54.07 |
| | The entry in teh CMAP does in fact map 10 to 15 (ie 0x0a->0x0f) | 15:54.42 |
| | The Cmap looks 100% | 15:55.18 |
| chrisl | Hmm, you confused me with "upside down"..... | 15:56.23 |
| kens | Sorry, I confused myself too. | 15:56.42 |
| | It just enumerates it, which is a random order... | 15:56.51 |
| chrisl | Yeh, that's what I was thinking - being a dictionary | 15:57.17 |
| kens | The Encoding just looks wrong | 15:57.26 |
| | It runs from /0 to /E3 with no gaps. | 15:57.41 |
| | I suspect only pdfwrite/ps2write care about this | 15:58.31 |
| henrys | alexcher are you around? | 15:58.55 |
| chrisl | Could be, surely it goes to /FF with no gaps..... | 15:59.09 |
| kens | Maybe, I'm just dumping the array with ==, I'll add a flush | 15:59.35 |
| | Yeah, all the way to 0xff | 16:00.03 |
| chrisl | okay, and no indices above 255 which would complicate things further | 16:00.34 |
| kens | You mean none above 255 in the Encoding or the font ? | 16:00.57 |
| chrisl | The font | 16:01.06 |
| kens | Yes, correct. | 16:01.11 |
| | May have to deal with that eventually ;-) | 16:01.24 |
| chrisl | It looks to me like it might be using the values on the stack in the wrong order | 16:02.46 |
| kens | Possibly, it seems like its the problem | 16:02.58 |
| chrisl | Hmm, nope..... | 16:04.34 |
| kens | Its definitely not filling hte array correctly though | 16:05.09 |
| | Oh, it looks like its defining the CharStrings.... | 16:05.51 |
| | It doesn't seem to be building the Encoding array at all | 16:06.04 |
| chrisl | It's doing both together | 16:06.13 |
| kens | Sorry, that's what I meant. | 16:06.20 |
| henrys | We need to put together a public pdf test files of about 150 files maybe - we have 70 or so in tests_public. Can any of you donate interesting pdf test preferably with a variety of functionality? Miles has promised this mistakenly to a customer. Thanks. | 16:06.27 |
| kens | Most of my test files are cut down to exhibit only one problem, teh bug.... | 16:07.06 |
| Robin_Watts | tor8: Are we free to redistribute zenikos set ? | 16:07.13 |
| tor8 | Robin_Watts: they've given permission before | 16:08.04 |
| Robin_Watts | tor8: I guess I should look at the rendering differences in pdfreference17 | 16:08.33 |
| henrys | kens:well if they are simple/fast and free/open they should really be checked into tests_public/pdf | 16:08.41 |
| kens | They generally are :-) | 16:08.54 |
| henrys | oh okay | 16:09.02 |
| Robin_Watts | henrys: We could look through the fixed bugzilla bugs for public PDF attachments ? | 16:10.14 |
| henrys | Robin_Watts:yes that might be reasonable, also alexcher has a large corpus of pdf files. | 16:11.48 |
| | pretty good suite here http://www.stillhq.com/pdfdb/db.html, I'll wait for alexcher, I think he should do this. | 16:17.31 |
| chrisl | kens: if I change cvrs to cvs at line 1734 in gs_ttf.ps (and remove the radix param), I get the right output from ps2write | 16:20.40 |
| sebras | Robin_Watts tor8 henrys: this one is also good: http://acroeng.adobe.com/ | 16:20.44 |
| kens | chrisl you beat me to it ;-) | 16:21.14 |
| henrys | thanks sebras | 16:21.28 |
| kens | I'd like to understand it so I'll look more for a few minuntes | 16:21.29 |
| chrisl | Yeh, I wasn't claiming that was *the* fix just an observation, right now | 16:22.12 |
| kens | There's definitely something wrong with the way tat array is built, I just can't quite figure out wjhat | 16:22.45 |
| chrisl | Well, it's not only being used by pdfwrite/ps2write, if I hack it about, it affects rendering, too | 16:23.50 |
| kens | THat's a worry | 16:24.15 |
| chrisl | I'm not sure the encoding is wrong, because all it needs to do is match the contents of the charstrings dictionary. I suspect something is assuming the values are decimal | 16:25.56 |
| kens | Its 'wrong' for ps2write.... | 16:26.30 |
| | Because if we execute the composite glyph GID 5 needs to be the correct glyph | 16:26.55 |
| chrisl | But that shouldn't go through the encoding, should it? | 16:28.07 |
| kens | But that operates inside the TT interpreter, and has no bearing on the CharStrings (or does it?) | 16:28.10 |
| | I htink htis is hte basic problem. | 16:29.10 |
| chrisl | what's the parameter to avoid compressing the ps2write output? | 16:29.44 |
| kens | We can't go around willy-nilly re-assigning the CharSTrings to values other than the GID | 16:29.44 |
| | -dCompressPages=false | 16:29.51 |
| chrisl | Thanks | 16:30.15 |
| kens | chrisl I'm puzzled why changing the array would affect the rendering if, as you say, it doesn't matter what the assignements are as long as htey match teh CharStrings | 16:32.28 |
| chrisl | i changed the encoding, I *didn't* change the charstrings | 16:33.21 |
| kens | Ah, well changing both would be good ;-) | 16:33.37 |
| chrisl | Yeh, I was only experimenting to see if it would affect devices other than pdf/ps2write | 16:34.06 |
| kens | I need to think about this. I'm pretty sure I can't solve it without changing this code though. | 16:34.56 |
| | We can't have ps2write using different GIDs. | 16:35.13 |
| chrisl | Does ps2write use the encoding and/or charstrings to decide which glyph index to place a glyph at in the output TTF? | 16:37.00 |
| kens | Yes, essentially, it uses the Encoding | 16:37.20 |
| henrys | tor8, Robin_Watts:sorry the test suite is for mupdf not ghostscript so alexcher is probably not the best person to do this and I'm not sure we print tests_public/pdf correctly with mupdf, tor8? | 16:37.31 |
| kens | Which is why I can't have a glyph move, because I *can't* move the GID fo the component glyph | 16:37.41 |
| | And if they collide we get the wrong answer | 16:37.54 |
| chrisl | kens: Oh, that seems, um, wrong. Can't it use the original GID? | 16:38.01 |
| kens | I don't believe we know it | 16:38.24 |
| chrisl | It doesn't have the charstrings array? | 16:38.36 |
| kens | No, I don't think so | 16:38.46 |
| chrisl | dictionary, doh! | 16:38.49 |
| kens | It has other stuff | 16:38.56 |
| marcosw_ | henrys and rayjj: I'm available for the support meeting today, but am running a bit behind. Would 9:45 or 10:00 be okay? | 16:39.05 |
| chrisl | So it has the encoding, but not the charstrings, yush..... | 16:39.18 |
| henrys | marcosw_:sure | 16:39.20 |
| marcosw_ | thx | 16:39.31 |
| kens | I could be wring, teh CharStrings might be available | 16:39.39 |
| henrys | sebras:has anyone tested mupdf with http://acroeng.adobe.com/ | 16:39.53 |
| kens | Actually we do have the CharStrings there | 16:40.20 |
| chrisl | I rather feel that using anything other than the original GID is just asking for trouble | 16:40.54 |
| kens | It is, yes, that's the whole problem. | 16:41.09 |
| | Looks like htis is a general purpose encode routine, so it uses teh Encoding because that's what it normally has | 16:42.27 |
| | I think I would prefer to get the Encoding and CharStrings right in the PDF interpreter rather than special case meddling with the encoding stuff | 16:43.03 |
| chrisl | Well, by most definitions the Encoding and CharStrings are "right" now, in that they're contents match each other | 16:44.02 |
| kens | Actually I think I'm a level too high here | 16:44.19 |
| | The fact that they match each other just means they are compatible, not 'right'. I'd prefer if the Encoding matched reality | 16:44.45 |
| | Right now it goes to a lot of trouble to extract hte CMAP and tehn in effect doesn't use the information | 16:45.03 |
| | 'Fixing' this in zfont_encode_char is not correct IMO. I think the Encoding array should match the CMAP array. So index 3 has CharString /4 and index 10 has CharString /15 etc. | 16:46.34 |
| chrisl | Hmmm, it probably shouldn't have /0 in the encoding array | 16:49.34 |
| kens | Theoretically no I guess. | 16:49.56 |
| henrys | tor8, Robin_Watts:so I need 150 test files that we suspect print correctly by tomorrow, sorry Miles has gotten us into a jam with this. I am sort of stuck since the mupdf testing results/processes aren't yet transparent like ghostscript and I really don't want to send broken files. | 16:52.03 |
| Robin_Watts | henrys: Crumbs, right. | 16:52.45 |
| | tor8: There are 345 files in your 'test.tar' archive. | 16:56.04 |
| | tor8: Where did the test.tar archive come from? Is that zenikos set ? | 17:00.07 |
| kens | chrisl it looks like its the use of non-numeric names which is causing me a problem. | 17:04.55 |
| | Using /A is bad, because /A is a perfectly reasonable glyph name.... | 17:05.32 |
| chrisl | kens: hence why we get the correct output using just cvs | 17:05.38 |
| kens | Yes. that works out correctly | 17:05.46 |
| | I htink the only solution here is to use decimal (numeric) names | 17:05.58 |
| chrisl | So, actually, the more I think about it, I don't see a problem with that - as long as the Encoding and Charstrings are compatible, the format of the entries/keys doesn't really matter | 17:06.46 |
| kens | I'll see about fixing the CharStrings dictionary as well in the morning. As long as both CharStrings and Encoding match .... | 17:06.55 |
| | What you said yes | 17:06.58 |
| | I have to go out now though, it should be an easy fix in the morning, then I can test it and hopefully make Till happy ;-) | 17:07.28 |
| | Goodnight all. | 17:07.38 |
| chrisl | have a good evening | 17:07.42 |
| Robin_Watts | tor8: ping | 17:08.46 |
| | tor8: I'm running through the test.tar thing, making a list of files we could use if we had to. | 17:35.29 |
| | OK, I have 50 files. I could do with a hand here tor... :) | 17:55.40 |
| tor8 | Robin_Watts: the test.tar is zeniko's set and some additional files | 17:58.51 |
| marcosw_ | henrys and rayjj: support meeting? | 17:58.57 |
| henrys | marcosw_:can you respond to horiana that we will take that as an enhancement request. | 17:59.00 |
| | and create an enhancement. | 17:59.14 |
| marcosw_ | okay. | 17:59.17 |
| henrys | ;-) | 17:59.19 |
| Robin_Watts | tor8: I'm running through test.tar from the start forwards checking each file to check it renders OK in mupdf vs acrobat. | 18:00.14 |
| tor8 | Robin_Watts: for henry's stuff? | 18:00.28 |
| Robin_Watts | If it doesn't look like it's confidential (like a bank statement for instance) and it renders OK then I'm making a note of it. | 18:00.43 |
| | tor8: yes. | 18:00.47 |
| tor8 | many of those files are quite broken | 18:00.50 |
| henrys | marcosw_:where shall we start? | 18:00.55 |
| tor8 | but it's a start | 18:01.04 |
| Robin_Watts | tor8: As long as we render the same as acrobat, that's fine, right? | 18:01.06 |
| tor8 | yeah | 18:01.12 |
| marcosw_ | I've lost track of when we last met; the week before thanksgiving? | 18:01.19 |
| Robin_Watts | We can say "these are a collection of files (some broken) that we've previously had trouble with". | 18:01.33 |
| | I'm at 682 now, so if you could start at the end and work backwards, we can meet in the middle. | 18:01.54 |
| henrys | Robin_Watts:there is some variety to them right? Not just simple text or something. | 18:02.59 |
| Robin_Watts | Some files have a single line on the page. | 18:03.17 |
| | some a single char. | 18:03.20 |
| | but the name of the file is like "669 - rendering error.pdf" | 18:03.40 |
| marcosw_ | henrys: let's start with 692692 (though that one has been fixed). | 18:03.48 |
| Robin_Watts | or "656 - crashes while rendering (filterless inline image).pdf" | 18:03.57 |
| tor8 | Robin_Watts: the numbers are sumatrapdf's bug numbers | 18:04.20 |
| Robin_Watts | right. | 18:04.24 |
| henrys | marcosw_:okay | 18:04.40 |
| marcosw_ | I think the first one that is worth discussing is 700 | 18:04.54 |
| henrys | is it worth bisecting? | 18:05.57 |
| marcosw_ | early versions of Ghostscript read the file badly | 18:06.30 |
| henrys | I don't know what else to do with it, you think the priority should be higher for band vs. non band - P3? | 18:07.06 |
| marcosw_ | It's presumably a pretty obscure issue, this is the only file that shows this behavior. I'm happy to leave it P4 until a customer trips over it. | 18:08.00 |
| henrys | I'm at 704 | 18:08.19 |
| marcosw_ | hold on, 702 and 703 appear to be duplicates. | 18:08.54 |
| | okay, I'm at 704. | 18:09.49 |
| | who_owns_what says michael is psdcmyk | 18:10.33 |
| henrys | 704 to alexcher for simplification and then off to ray or michael. | 18:10.35 |
| marcosw_ | sold. | 18:10.53 |
| | 706? | 18:12.06 |
| henrys | looks right to me. | 18:12.28 |
| | assigned to ray | 18:12.35 |
| marcosw_ | hopefully it's the same problem as 692542 | 18:12.41 |
| | do you want to look at 707 since it only happens on your cluster node? | 18:13.37 |
| henrys | yeah I can probably add some detail at least | 18:13.53 |
| marcosw_ | it appears that Ray's commit broke it, but probably just moved things around in memory. | 18:14.18 |
| henrys | uhoh 708 is a bomb | 18:14.33 |
| | I would close 709 with an invitation to reopen. | 18:15.41 |
| marcosw_ | looks like 708 has been fixed in the master. | 18:15.49 |
| | ^708^709 | 18:16.04 |
| henrys | 710 could be changed to an enhancement. | 18:17.15 |
| marcosw_ | closed 709 | 18:17.17 |
| henrys | IMHO | 18:17.18 |
| marcosw_ | i agree, since there is a workaround. | 18:17.46 |
| | I'll leave 711 with Ken, I could reproduce it first, but I presume Till knows what he's doing. | 18:18.41 |
| henrys | 712 might be worth reproducing in acrobat. | 18:19.42 |
| marcosw_ | I'm not sure I understand 712. | 18:19.45 |
| | okay, now I do. The use of the pspcl6 binary confused me. | 18:20.23 |
| henrys | oh I didn't even notice that. | 18:20.43 |
| marcosw_ | I'll take 712 for reproducing. | 18:20.44 |
| | I took 720 to reproduce. | 18:22.11 |
| henrys | you jumped ahead of me, skipping | 18:22.36 |
| marcosw_ | Do you want 721 to go to Michael or should Alex look at it first. | 18:22.40 |
| henrys | michael francois has already broken things down | 18:23.23 |
| marcosw_ | looks like the user already generated simplified test cases. | 18:23.31 |
| | Do we know who Francois is? We should hire him :-) | 18:23.50 |
| henrys | I tried that. | 18:24.04 |
| marcosw_ | should 722 be an enhancement? | 18:24.48 |
| henrys | I'll fix 722 if somebody tells me what to do ;-) | 18:25.26 |
| | yes enhancement | 18:25.40 |
| | it should be consistent with whatever gs does. | 18:25.50 |
| | afp usually means commercial use - no one would mess with that sans pay. | 18:27.14 |
| | 723 | 18:27.20 |
| marcosw_ | yes. I was just reading 723. | 18:28.09 |
| chrisl | I'll reply to 723, the Postscript is broken | 18:28.27 |
| henrys | so assign to chrisl | 18:28.40 |
| chrisl | Just done so.... | 18:28.52 |
| marcosw_ | okay. | 18:28.55 |
| henrys | I'll report them to miles and scott fwiw | 18:29.03 |
| Robin_Watts | tor8: We should send "826 - diagram missing.PDF" to scott. | 18:29.10 |
| henrys | so on 725 it isn't clear these should be customer problems but just leave it for now. | 18:30.41 |
| tor8 | indeed! | 18:30.44 |
| marcosw_ | and 727 and 728 don't need to be discussed. | 18:32.18 |
| henrys | 727 should be close right? | 18:32.34 |
| | yeah! | 18:33.24 |
| marcosw_ | I've reassigned 727 to Ken to reduce the mediabox (it's password protected, so I can't do it myself). | 18:33.35 |
| henrys | looking at support problems. | 18:34.01 |
| | 692650 can go to Robin_Watts | 18:34.23 |
| marcosw_ | done. | 18:35.38 |
| | 652 as well? | 18:35.58 |
| Robin_Watts | OK, that looks like a hangover from handling flipped images or something. | 18:36.00 |
| henrys | 652 to ray | 18:36.01 |
| marcosw_ | why ray? | 18:36.20 |
| henrys | generic device stuff | 18:37.31 |
| marcosw_ | okay. | 18:37.53 |
| | 659 was missing the customer number (oops), I've fixed it. | 18:38.09 |
| henrys | 659 to alex? | 18:38.19 |
| chrisl | Isn't that just another missing CIDFont issue? | 18:38.59 |
| marcosw_ | I'm not sure that 659 is a bug. | 18:39.06 |
| chrisl | The file for 659 runs to completion without error in my CIDFont substition code, so it is a duplicate | 18:40.20 |
| henrys | 663 is a good one for robin_watts to look at but it, is reproducible with alpha bits and a normal printer device so he doesn't need x11? | 18:40.25 |
| Robin_Watts | I have X. | 18:41.04 |
| | I can run Ubuntu in a VMware instance. | 18:41.17 |
| henrys | yes I know but I assumed it would be easier and less time | 18:41.48 |
| marcosw_ | I'm not sure about 659, with the modified cidfmap I now see a seg fault. | 18:42.17 |
| henrys | marcosw_:can you just drop in 692665 and smoke test it for no crashing. | 18:42.36 |
| marcosw_ | sure, just apply and clusterpush :-) | 18:43.13 |
| | except for that we haven't added the ability to specify a device yet :-( | 18:43.36 |
| | I'll smoke test it, I've assigned it to me. | 18:44.11 |
| henrys | okay. | 18:44.29 |
| | miles just sent mail about the mupdf customer problems so can you change those marcosw_? | 18:45.36 |
| Robin_Watts | tor8: I hve 96 potential files so far. How you doing? | 18:46.29 |
| marcosw_ | henrys: will do. | 18:47.16 |
| | should I leave the customer number and change the bugs to P4 or remove the customer number as well? | 18:48.50 |
| henrys | how does it affect the tallies? | 18:49.44 |
| | we were striving to get the bug count down and these shouldn't count. | 18:50.02 |
| marcosw_ | I think the presence of a value in the customer field counts towards to reports. So I'll remove the customer number. | 18:52.50 |
| henrys | okay we could make them p3 if we think they should be more important than regular users - maybe Robin_Watts or tor8 have an opinion. | 18:53.32 |
| Robin_Watts | henrys: sorry, which bugs are we talking about? | 18:53.55 |
| henrys | Robin_Watts:probably the fastest thing is to read Miles' latest email. | 18:54.22 |
| Robin_Watts | right. | 18:54.45 |
| | I think we've fixed all but 1 of their problems already. | 18:54.57 |
| | I'd say put them in without a customer number. | 18:55.18 |
| marcosw_ | Robin_Watts: there are (were) three open muPDF issues unrelated to text extraction. | 18:55.22 |
| | I've changed them to P4 and removed the customer number. I'll add the remaining issues in the same way. | 18:55.46 |
| Robin_Watts | marcosw_: 2 of which have been fixed, but haven't been closed as the patches haven't made it to the main repo yet. | 18:55.48 |
| | Fab. | 18:55.50 |
| marcosw_ | I'm going to drive home, will be back online later. | 18:57.51 |
| Robin_Watts | tor8: ping | 19:51.30 |
| tor8 | Robin_Watts: pong! | 19:51.52 |
| Robin_Watts | On casper in my home dir there is a test.tgz file with 140 files in it. | 19:52.07 |
| | If you add the 10 from sane, that should do. | 19:52.23 |
| | I can't easily do it myself, because anything that involves me uploading is going to be SLOW. | 19:52.46 |
| | if you've found any others that can be used, then add them too. | 19:52.57 |
| | I got to 1185 before I gave up. | 19:53.08 |
| | got torun to shop. | 19:54.15 |
| tor8 | Robin_Watts: I'm a bit confused, the test.tgz is full of files from sane... | 19:54.41 |
| | Robin_Watts, henrys: these files, must they be PDF or are XPS wanted as well? | 19:56.12 |
| henrys | pdf | 20:06.49 |
| Robin_Watts | tor8: Yes. | 20:51.34 |
| | As I said earlier I went through the sane set selecting files that we render correctly. | 20:52.19 |
| | and that didn't have anything obviously confidential in. | 20:52.42 |
| tor8 | yeah, and then you said "If you add the 10 from sane, that should do." | 20:54.40 |
| Robin_Watts | Sorry, the 10 from the 'quick' sane test. | 20:54.55 |
| tor8 | ah, those! I think those are merged with the ones in the test.tar I uploaded | 20:57.00 |
| | Forward 1 day (to 2011/12/09)>>> | |
IRC Logs