| | <<<Back 1 day (to 2019/09/29) | Fwd 1 day (to 2019/10/01) >>> | 20190930 |
| sebras | I'm not sure how to interpret the differences I see in how ghostscript behaves in bug 701638. perhaps I'm mistaken in expecting png16m and x11 devices to render identically? | 01:01.31 |
| | png16m is identical to acrobats rendering, but rendering to x11 is not. | 01:02.08 |
| chrisl | sebras: I wouldn't trust the X11 devices, personally. Also, I wouldn't use Text/GraphicsAlphaBits with any file with transparency in it. | 06:31.35 |
| sebras | chrisl: I know very littel about what command line parameters are suitable for ghostscripts in different cases. I blindly copied from https://www.ghostscript.com/doc/9.21/Devices.htm#PNG | 09:56.34 |
| | chrisl: does this imply a bug in ghostscript's x11 device? | 09:57.02 |
| kens | sebras, your results look (to my ill-informed opinion) rather like the resutls Michael and possibly Ray fixed in GS some time ago. Text in a group (between BT/ET) should be treated as if in an isolated transparency group (IIRC). So that overlapping glyphs do not apply transparency. There's a test file which demonstrates it. Of course, thi may be somethign entirely diffferent. | 09:58.08 |
| | No idea why the X11 device would behave differently though | 09:58.27 |
| chrisl | sebras: Well, firstly, the default is normally x11alpha - which effectively does the same as setting TextAlphaBits and GraphicsAlphaBits - and those are fundamentally not compatible with the transparent imaging model | 09:59.04 |
| | sebras: There are also some oddities in the way that the X11 devices work that I'm not convinced are sensible (particularly to do with color models) - hence I don't trust it! | 10:01.02 |
| kens | x11alpha might be a problem, yes | 10:01.40 |
| sebras | ok, so then I presumably used x11alpha. | 10:02.12 |
| chrisl | So, the problem is the extra dark bands? | 10:03.12 |
| sebras | I wasn't aware there were two. :) | 10:03.16 |
| chrisl | There are *several* | 10:03.26 |
| kens | chrisl, yes | 10:03.26 |
| | I think sebras means two devices | 10:03.39 |
| sebras | the extra dark bands are the differences to acrobat at least. | 10:03.44 |
| chrisl | x11 x11alpha x11cmyk x11cmyk2 x11cmyk4 x11cmyk8 x11gray2 x11gray4 x11mono x11rg16x x11rg32x | 10:03.50 |
| kens | Too many :-( | 10:04.01 |
| sebras | is apparently uninformed. | 10:04.03 |
| chrisl | Right so if you drop the AlphaBits params, and/or use -sDEVICE=x11 the results, I think, are correct | 10:04.22 |
| sebras | then it matches acroread. | 10:04.50 |
| | just using -sDEVICE=x11alpha without AlphaBits does not match acroread. | 10:05.15 |
| chrisl | Yes, x11alpha sets alphabits automatically | 10:05.39 |
| | sebras: Did you try mupdf with anti-aliasing disabled? | 10:06.10 |
| sebras | kens: perhaps acroread draws the text like a non-isolated knockout group? least if I compare to plate 17 on page 1147 of pdfref17.pdf | 10:06.52 |
| kens | sebras I don't recall the details I'm afraid | 10:07.09 |
| | But don't forget there's a text knockout parameter as well | 10:07.25 |
| sebras | chrisl: I did not. there is an -A 0 setting, but it draws it the same. | 10:07.44 |
| chrisl | Well, it's very dependent on how the aa is implemented | 10:08.07 |
| sebras | kens: right, I'm just trying my best to put what I see into words. :) | 10:08.13 |
| kens | I think the png resutl you see, which matches Acrobat, is correct. The results from GS which are incorrect are due (I believe) to using anti-aliasing | 10:08.45 |
| sebras | chrisl: for mupdf I did file a bug because I couldn't get mupdf to match acroread. but I was more uncertain about gs. | 10:08.55 |
| kens | Which is, as Chris said, basically incompatible with PDF transparency | 10:08.58 |
| kens | thinks GS is 'correct' | 10:09.12 |
| | For given values of correctness based on the parameters | 10:09.22 |
| sebras | maybe there is no bug in mupdf either then. | 10:09.55 |
| | it's just that anti-aliasing can't be turned off like in gs. | 10:10.31 |
| | perhaps ator can chime will chime in on this. | 10:10.46 |
| kens | I can't say for sure, but the inability to turn off AA may well result in problems like this | 10:10.46 |
| chrisl | But mupdf *can* turn off AA | 10:11.03 |
| kens | yes, but x11alpha in GS can't | 10:11.18 |
| | I can't really say what MuPDF is up to | 10:11.34 |
| chrisl | Actually, you can turn off aa in x11alpha: -dTextAlphaBits=1 | 10:12.30 |
| kens | That actually works ? I'm surprised | 10:12.42 |
| chrisl | I can't help but feel there ought to be a way to make the alpha bits stuff work with transparencyt | 10:14.57 |
| ator | sebras: kens: I don't think the dark overlapping parts have to do with AA at all | 10:15.06 |
| | they're just overlapping transparent parts | 10:15.11 |
| kens | They could be what I was describing earlier | 10:15.22 |
| | Where two glyphs in a transparenct text block overlap | 10:15.34 |
| | Michael had to fix that for GS | 10:15.40 |
| | If I could remember the name of the Altona test file I'd get it and text it with MuPDF | 10:16.01 |
| ator | the proper "solution" is to draw all text in a text operator into a separate mask, and *then* composite it | 10:16.03 |
| kens | Yes, that's effectively whhat GS does AIUI | 10:16.18 |
| ator | so basically make a transparency group to render the entire TJ operation | 10:16.25 |
| kens | we do that by creating a group for the text | 10:16.26 |
| | Its more than just the Tj its teh entire BT/ET group, I think | 10:16.43 |
| ator | kens: hm, yes, probably true. | 10:17.05 |
| kens | Because we had problems with files that do 'other stuff' between BT/ET and some which lack an ET altogether | 10:17.09 |
| sebras | ator: right, that's what I tried to say by saying non-isolated knockout group above. | 10:17.24 |
| ator | like when using text with the "clipping" text rendering mode | 10:17.31 |
| kens | Of course, for those files, which are plainly wrong, I'm not bothered by getting the wrong result | 10:17.34 |
| sebras | ator: but my vocabulary is not good enough. :) | 10:17.37 |
| kens | ator, yes, just like TR 5-7 | 10:17.50 |
| ator | question is, do we do the transparency groups implicitly in the draw device if the text is transparent | 10:19.30 |
| | or do we make it the responsibility of the interpreter | 10:19.39 |
| kens | Hmmm | 10:19.56 |
| ator | I think we'd want to ask Robin, he's the transparency guru in mupdf :) | 10:20.08 |
| kens | Well that's an implementation detail. | 10:20.11 |
| | In GS I'm pretty certain we have to push the group at the interpreter levell (no choice) | 10:20.29 |
| ator | kens: yes. what's clear is that we do need to make a temporary transparency group whenever text is transparent. | 10:20.30 |
| | it'll be bad for performance, but if you use transparent text, you get what you deserve. | 10:20.43 |
| chrisl | kens: Except for in one case.... | 10:20.49 |
| kens | Yes, the performance issue is why we tried to avoid it, I think | 10:20.56 |
| ator | kens: yeah, except we have to deal with XPS and SVG etc too | 10:21.00 |
| kens | Well, we also have XPS :-) | 10:21.14 |
| | But I think its easier to deal with | 10:21.19 |
| | chrisl which case ? | 10:21.51 |
| chrisl | kens: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=73bd448d2ebabad9ee31053abf897325a639cba1 | 10:22.04 |
| kens | Ah yes, Robin's new code. | 10:22.21 |
| | I'd guess that's entirely applicable to XPS too ? | 10:22.42 |
| chrisl | Probably | 10:23.03 |
| kens | So its fair enough to stick it in the graphics library then, I guess | 10:23.20 |
| chrisl | It's about drawing internally generally color samples | 10:23.21 |
| sebras | ator: I manipulated overlap.pdf so that the two text strings overlap. they are still within the same BT/ET but one's in a Tj and the other in a TJ. in acroread there is no visible dark bands. I think that proves that the acroread draws the entire BT/ET as a single transparency group..? | 10:25.25 |
| ator | sebras: what if you split the overlapping text so each half is in a different BT/ET group? | 10:29.37 |
| sebras | I can try to do that in a bit. | 10:29.51 |
| kens | let me see if I can find the exhibit file for this in GS | 10:30.09 |
| | Hmm, no can't find it sorry | 10:35.18 |
| sebras | ator: I added that case a overlap3.pdf with corresponding screenshots of overlapping text objects in https://bugs.ghostscript.com/show_bug.cgi?id=701638 | 10:48.45 |
| ator | yup! looks like I had hoped. | 10:51.39 |
| | (in acroread) | 10:51.43 |
| sebras | ator: and the same renders for ghostscript look reasonable too. | 10:54.55 |
| | kens: chrisl: so in the end gs had no issues, except for when alpha is enabled and that was already known. and there is no point in filing a bug for gs x11alpha, right? at least that's how I understood it. | 10:56.34 |
| kens | I wouldn't | 10:56.53 |
| | There's not really anything we can do about it | 10:57.01 |
| sebras | kens: ok, just wanted to make sure I didn't misinterpret the discussion. :) | 10:57.38 |
| kens | :-) | 10:57.44 |
| Robin_Watts | oof, that's a pain to fix. | 11:21.23 |
| | It means every non-completely-opaque text object needs to have its own knockout group. | 11:22.19 |
| | but how do you bound the knockout group at creation time? | 11:22.32 |
| kens | IIRC Ghostscript uses the page BBox | 12:00.43 |
| | There is no BBox for the text group | 12:00.52 |
| rsc | If I get the output "Error: /invalidfileaccess in /findfont" of a Ghostscript embedded into another software, can I make Ghostscript somehow more verbose to figure out which filename it talks about? | 18:06.47 |
| | ("embedded into" as in "called by" | 18:07.24 |
| kens | rsc Ghostscript is already more verbose, what you haev quoted is not the entire back channel output from Ghostscript when it encounters an error | 18:12.33 |
| rsc | kens: urgs, let me see where the rest ends up... | 18:13.28 |
| kens | If Ghostscript is being run with -q or -dQUIET or -dSHORTERERRORS or any similar switch then you would need to remove that | 18:14.12 |
| rsc | Ha! | 18:19.26 |
| | Is there a list of paths which -dSAFER prevents access to? | 18:21.38 |
| kens | Everything | 18:21.45 |
| | Files specified on the command line are permitted | 18:22.15 |
| | Files in -I are added IIRC | 18:22.27 |
| rsc | Okay...I'm here on RHEL 7, which had like Ghostscript 9.07, where it was allowed to access the font files, even with -dSAFER. Since upgrading to 9.25 (RHEL 7.7) -dSAFER blocks font file access. | 18:22.33 |
| kens | I didn't think 9.27 did that, but its possible | 18:22.55 |
| | You could try the pre-release 9.28 | 18:23.00 |
| | There have been many more changes surrounding SAFER nd file access | 18:23.11 |
| kens | is off for the night | 18:29.06 |
| | If you have further questions, note them here and I'll read the logs in the morning | 18:29.23 |
| | <<<Back 1 day (to 2019/09/29) | Forward 1 day (to 2019/10/01)>>> | |
Log of #ghostscript at irc.freenode.net.