| | <<<Back 1 day (to 2018/03/13) | 20180314 |
| tor8 | velix: mutool clean '-s' is an experimental feature | 00:28.58 |
| | you want '-g' to remove unused objects\ | 00:29.09 |
| velix | tor8: Yeah, can I report a bug ? | 00:29.11 |
| tor8 | yes, at bugs.ghostscript.com. please attach the input file and write your command line in the comment as well, so we can reproduce easily. | 00:29.43 |
| velix | tor8: I tried g and gggg, but it doesn't go away ;) | 00:29.44 |
| | tor8: yes, I will. | 00:29.50 |
| tor8 | well, then it might just be used :) | 00:29.56 |
| velix | loves to make software better. | 00:29.58 |
| tor8 | I'll take a look tomorrow, it's time to log off and get some sleep now | 00:30.06 |
| velix | okay, good night. 01:30 am here. | 00:32.12 |
| ohir | :) hi, whomever alive. | 07:11.45 |
| tor8 | Robin_Watts: I've found a file that shows some significant problems with our non-AA rasterizers | 11:46.43 |
| | memory overwrites with 'cop' and missing graphics with aa<8 | 11:46.59 |
| Robin_Watts | tor8: crap. | 11:47.05 |
| tor8 | template_solid_color_0_da has an 'invalid write of size 1' in the memset | 11:47.27 |
| Robin_Watts | Can you open a bug and I'll take a look? | 11:47.54 |
| tor8 | and a quick glance at the profiler seems to indicate an issue with nonseparable blends for aa0..aa7 | 11:47.59 |
| | Robin_Watts: will do. the file is rather big though... | 11:48.28 |
| | Robin_Watts: 699109 and 699110 | 11:55.49 |
| Robin_Watts | It's overwritting pattern pixmap tiles. | 12:25.05 |
| | tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=b925766ea8794f1924ce0dea9fa942966dea3350 | 13:11.45 |
| tor8 | Robin_Watts: are you sure? it gets 'right' from the row buffer later and compares with pr | 13:15.18 |
| | is that 'right' also an offset from the left or absolute value? | 13:15.32 |
| velix | tor8: Sorry, I was fallen asleep yesterday. | 13:22.51 |
| Robin_Watts | tor8: It reads right from the row buffer. | 14:18.30 |
| | Then fixed2ints it, and subtracts pl. | 14:18.41 |
| | Hence pr should have pl subtracted from it too. | 14:19.04 |
| | I've stepped through to the exact point it goes wrong. | 14:19.19 |
| Robin_Watts | slaps tor8 for bug 699110. | 14:22.10 |
| | "Many graphic elements missing". Well, tell me some specifics, or give me a screenshot. | 14:22.31 |
| tor8 | Robin_Watts: compare a render with aa8 and aa0 | 14:22.51 |
| Robin_Watts | I'm comparing against acrobat reader, and can't immediately see anything unexpected. | 14:23.12 |
| tor8 | Robin_Watts: let me get you some files | 14:23.50 |
| | Robin_Watts: it was *very* obvious when I saw it... | 14:33.10 |
| | okay, it differs between 'mutool draw' and 'mutool convert' | 14:35.25 |
| | Robin_Watts: try mutool convert -o out%d.png -O graphics=aa0 Board*.pdf | 14:35.57 |
| | https://ghostscript.com/~tor/out1.png is what I see | 14:36.52 |
| Robin_Watts | urm... | 14:37.09 |
| | platform/win32/memento/mutool.exe convert -o ref.png -O graphics=aa0 b.pdf | 14:37.25 |
| | doesn't produce a ref.png for me. | 14:37.53 |
| tor8 | it always tacks on the page number if the %d is missing for single-page formats | 14:38.13 |
| Robin_Watts | Aha. | 14:38.25 |
| tor8 | so you sohuld have a ref1.png | 14:38.26 |
| Robin_Watts | I see what you mean :) | 14:38.30 |
| tor8 | Robin_Watts: fix for 699109 LGTM then | 14:39.34 |
| Robin_Watts | aa7 looks good. | 14:39.44 |
| tor8 | aa7 rounds up to 8 I think | 14:39.52 |
| Robin_Watts | aa6 it looks faint... | 14:40.09 |
| tor8 | yeah. that looks weird. | 14:40.59 |
| | maybe you could say aa6 is 1/4 transparent | 14:41.16 |
| | yeah, aa4 looks even fainter | 14:41.33 |
| Robin_Watts | Ok. I'll dig in. ta | 14:42.14 |
| tor8 | strange that mutool draw doesn't seem to exhibit the same issue | 14:42.36 |
| | could be some difference with the AA context passing it through the draw device options (which mutool convert does) and setting the global default (which mutool draw does) | 14:43.49 |
| Robin_Watts | tor8: yeah, the context values are different, but then hopefully we're not looking at them. | 14:49.24 |
| | If I override the context values, we get the right thing. | 14:56.28 |
| | So, somewhere we are looking in the wrong place. | 14:56.34 |
| | specifically, it's aa->scale that's being accessed. | 14:59.22 |
| | In undelta_aa, I'd guess. | 15:00.14 |
| sebras | tor8: should pdf_annot_da() be renamed pdf_annot_default_appearance() perhaps? | 15:05.12 |
| tor8 | sebras: possibly, yes. | 15:06.27 |
| Robin_Watts | tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=ac07d0939ca372e585ac015f048f1b2267ad6f4f | 15:21.47 |
| | scratch that. I'll do a nicer one. | 15:25.26 |
| velix | Can I convert versions with mutool ? | 15:26.23 |
| Robin_Watts | no. | 15:26.45 |
| velix | Ok. | 15:27.07 |
| Robin_Watts | tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=461b81547c1328b819ee626a3f9b55c044b45dcd | 15:29.10 |
| sebras | tor8: would it make sense for pdf_set_annot_da() to allow for setting g, rg or K? | 15:59.37 |
| | perhaps k. | 15:59.43 |
| tor8 | sebras: no. let's just work in RGB. | 16:00.15 |
| | Robin_Watts: LGTM | 16:01.00 |
| Robin_Watts | pushed and closed. | 16:02.38 |
| velix | tor8: I've just filed my first bug report for Ghostscript ;) | 16:03.42 |
| kens | is not seeing a Ghostscritp bug report | 16:04.40 |
| | Possibly a MuPDF report ? | 16:05.09 |
| malc_ | kens: you just misspelled Ghostscritp | 16:06.38 |
| kens | I misspell *everything* | 16:06.51 |
| malc_ | must be a British thing | 16:08.48 |
| velix | malc_: I am Germany :D | 16:10.30 |
| | malc_: German | 16:10.35 |
| | oh my :DD | 16:10.37 |
| malc_ | Du bist Deutsch verdammt! | 16:11.00 |
| velix | kens: Yes, muPDF (muTools), but it's on the Ghostscript bugtracker. | 16:11.02 |
| | malc_: Yes. | 16:11.10 |
| sebras | tor8: just to get it out of my system: I love java. | 16:44.41 |
| tor8 | sebras: I've now examined how acrobat handles fonts and content streams for (a) cyrillic, and (b) chinese text, where the base14 aren't good enough | 16:55.32 |
| | in case (a) it embeds a subset font | 16:55.39 |
| | in case (b) it creates a non-embedded CID-font using the UniJIS-UTF16-H encoding | 16:56.12 |
| sebras | and for my dear mandarin..? | 16:56.12 |
| tor8 | so, japanese :) | 16:56.19 |
| sebras | I'm sure chinese nationals would be thrilled if they knew. :) | 16:56.49 |
| tor8 | it might do something smarter if I pick a chinese font, still need to test that out | 16:56.58 |
| | I have cooked up a 'pdf_add_cjk_font' to create a non-embedded CJK font resource for use with 'mutool create' and eventually freetext and widget appearance streams | 16:57.38 |
| | so now you can add a CJK font to the mutool create with "%%CJKFont Ming GB1" and then use it with UTF-16 encoded strings to Tj | 16:58.15 |
| | so /Ming 16 Tf <4F60 597D> Tj should say hello | 16:58.50 |
| | I wonder if we could cook something up for the other Unicode scripts as well | 16:59.08 |
| | or at least cyrillic and greek, where *our* base14 fonts have the glyphs | 16:59.26 |
| sebras | I keep forgetting about mutool create. | 16:59.58 |
| | how do you plan to detect if pdf_add_cjk_font() needs to be called when fiddling with the appearance streams? | 17:01.23 |
| tor8 | if the character is unencodable I'll look at the unicode script and pick/create an appropriate font | 17:02.11 |
| sebras | as I understand it this would allow for doing form-filling or freetext editing and when a font is missing (for CJK) we can seamlessly add it to the PDF. | 17:02.25 |
| tor8 | yes. that's the general idea. | 17:02.39 |
| | the current code is horribly limited in terms of its font and encoding handling (it just puts on a blindfold and ignores the problem) | 17:02.57 |
| sebras | this is better than we can do today. I won't complain. | 17:03.55 |
| | tor8: ah, so you'd call ucdn_get_script() and detect if it is... UCDN_SCRIPT_HAN. | 17:05.24 |
| | quite possibly HIRGANA, KATAKANA and BOPOMOFO as well. | 17:05.49 |
| tor8 | I'm thinking maybe a pdf_add_unicode_font(ctx, doc, font, script) that does unicode for a subset of the UCDN_SCRIPT_xxx fonts | 17:05.51 |
| | or 'script' should be one of the standard pre-unicode character sets roughly corresponding to latin-1 but for greek/cyrillic | 17:06.17 |
| | koi8 is it? | 17:06.20 |
| sebras | now you've lost me. :) | 17:06.38 |
| tor8 | sebras: for the non-CJK fonts it's more difficult because there are no default/built-in mechanisms to do unicode with those | 17:07.00 |
| | sebras: it's always possible to do a pdf_add_cid_font and embed the font we need. but I hope to be able to avoid doing that. | 17:07.32 |
| sebras | ok, so how would you go from ucdn_get_script() returning UCDN_SCRIPT_CYRILLIC to then embedding a suitable font? | 17:08.58 |
| sebras | looks up koi8 | 17:09.10 |
| | ok, like latin-1, but for cyrillic. | 17:09.57 |
| | tor8: oh, in JNI for inner classes, you need to supply the enclosing class as an argument to the constructor. | 17:29.52 |
| | tor8: it was only throught the tip of using javap and disassembling the enclosed class class-file that I discovered this. | 17:30.16 |
| velix | tor8: Do you have time to have a look at 699111 ? | 17:38.03 |
| tor8 | velix: not right now, sorry. you'll also need to be a bit more specific than "processing a PDF". put the actual command line you use in a comment. | 17:42.53 |
| velix | tor8: ANY command. But okay. | 20:41.38 |
| | I've updated bug #699111 | 20:53.44 |
| | Forward 1 day (to 2018/03/15)>>> | |
Log of #mupdf at irc.freenode.net.
