| | <<<Back 1 day (to 2019/07/01) | Fwd 1 day (to 2019/07/03) >>> | 20190702 |
| bodqhrohro_ | How can I properly convert all images to lossless CMYK? -sColorConversionStrategy=CMYK -sColorImageFilter=/FlateDecode returns 'Unrecoverable error: rangecheck in .putdeviceprops' for me. | 08:53.00 |
| kens | You haven't specified a full command line there, presumably you are using pdfwrite. What do you mean by 'lossless CMYK' ? What version of Ghostscript are you using ? | 08:53.45 |
| | Oh you can't use Flate*Decode* for Encoding images | 08:54.15 |
| | You want /FlateEncode | 08:54.20 |
| | Decode is for decompressing images, if you want to specify Flate for compressing images, you need to use FlateEncode | 08:54.46 |
| bodqhrohro_ | kens: thanks, `gs -dBATCH -dNOPAUSE -dPDFSETTINGS=/printer -sColorConversionStrategy=CMYK -dColorImageFilter=/FlateEncode -sDEVICE=pdfwrite -sOutputFile=bpp.pdf b.pdf` works. Though, it still spoils the quality :/ Probably the presets from PDFSETTINGS override it? | 08:59.59 |
| kens | The PDFSETTINGS parameters are applied first, tehn the later settings. Most likely the image is being downsampled to a lower resolution, though obviously I can't tell without seeing it. Try dropping PDFSETTINGS altogether and use the defualts, if you are after quality, then that's the best setting. | 09:01.14 |
| bodqhrohro_ | kens: it became even worse without the preset https://pic4a.ru/97/JVB.png Are there some other compressions turned on by default? | 09:31.28 |
| kens | No, by default the input is preserved into the output as closely as possible | 09:31.52 |
| | That still looks like DCT quantisation to me | 09:32.10 |
| | Which would suggest that its not using Flate compression | 09:32.40 |
| | I'd need the original PDF file and the command line to investigate | 09:32.54 |
| | Or at least, *an* original file | 09:33.08 |
| | Doesn't have to be that one, any one that exhibits the problem | 09:33.20 |
| bodqhrohro_ | kens: https://0x0.st/z_Va.pdf | 09:33.49 |
| kens | OK Give me a minute | 09:34.13 |
| bodqhrohro_ | pdfimages shows that the original is image-encoded, but the output is jpeg-encoded for some reason. | 09:34.13 |
| kens | Yeah it looks like JPEG quantisation like I said | 09:34.35 |
| | Oh you probably need to set AutoFilterImages to false | 09:36.49 |
| bodqhrohro_ | kens: thanks | 09:37.45 |
| kens | Yeah if I set AutoFilterColorImages=false, the output is much improved | 09:38.14 |
| | I'm afraid you have to blame Adobe for the complexity of the Distiller Params | 09:38.42 |
| | Quick check on the output shows the image is in DeviceCMYK and teh filter is FlateDecode | 09:41.16 |
| bodqhrohro_ | kens: does the "default" column here show the parameters that gs applies when no PDFSETTINGS preset and no following parameters are explicitly specified? https://ghostscript.com/doc/9.20/VectorDevices.htm#distillerparams | 09:47.16 |
| kens | 'default' is what you get when you don't set PDFSETTINGS | 09:48.03 |
| | Then each column describes the setting for the various PDFSETTINGS | 09:48.24 |
| | Obviously, if you override any parameters, that's what you get. | 09:48.36 |
| | Note that the command line is processed in order left to right | 09:48.51 |
| | So rightward parameters will override eariler ones | 09:49.07 |
| | You can use that to set PDFSETTINGS and then override individual parameters. | 09:49.21 |
| | But to be frank, I would prefer myself to use the defaults and override specific settings. | 09:49.39 |
| bodqhrohro_ | That makes a lot of sense now, thanks. | 09:50.23 |
| kens | NP | 09:50.27 |
| Wolfram | Since the update from Windows 7 to 10, ghostscript (tried 9.16/9.20/9.23) complains that "Calibri cannot be embedded because of licensing restrictions" when generating PDFs | 14:20.52 |
| kens | I guess the licence for Calibri has changed then | 14:21.16 |
| Wolfram | "Font embeddability" is "Editable" in C:/Windows/Fonts for all "Calibri" fonts. That should allow embedding, shouldn't it? | 14:21.54 |
| kens | As I recall there is a specific flag for permitting embedding | 14:22.23 |
| | In TrueType fonts | 14:22.28 |
| Wolfram | Can I ask ghostscript to tell me the exact ttf it uses? | 14:22.54 |
| kens | It will tell you | 14:23.08 |
| chrisl | Unless you use -dQUIET or -q | 14:23.23 |
| kens | Yeah I was getting to that :-) | 14:23.32 |
| Wolfram | hm, I have -dBATCH but not -dQUIET. Let me try again... | 14:25.10 |
| kens | Paste the transcript to pastebin or soemthing, then we can look at it | 14:25.27 |
| chrisl | You'll get messages like: "Loading ArialMT font from /usr/share/fonts/truetype/msttcorefonts/arial.ttf... 4774800 3437328 4470188 3152015 1 done." | 14:26.07 |
| kens | According to my comment in the code the fstype parameter is a bitfield and we forbid embedding if either bit 1 or bit 9 is set. bit 1 "Fonts must not be embedded, modified or exchanged in any manner" bit 9 "Bitmap embedding only" | 14:27.50 |
| | My version of calibri has fstype = 0x0008 | 14:29.51 |
| | So I believe it should embed | 14:30.05 |
| | That's the curren version of Windows 10 (I forget the exact build number) | 14:30.46 |
| Wolfram | https://pastebin.com/0cEqZvmk | 14:31.40 |
| kens | Looks to me like the font is embedded in the input file, since GS isn't loading it. | 14:32.27 |
| chrisl | So, it's probably illegally embedded in the input | 14:32.34 |
| kens | That's plausible if its a PostScript file created under Windows | 14:32.40 |
| | chisl in this sense 'illegally' is a bit strong perhaps. | 14:33.03 |
| chrisl | In contravention of the preferences of the copyright holders | 14:33.27 |
| kens | I think its possible for the printing system to embed the font *for printing* but flag it as not embeddable to prevent people making it into a PDF file for example | 14:33.37 |
| chrisl | Either that or the embedding application has messed up the flags..... | 14:34.20 |
| kens | Well, if it subset the font, it coudl easily change the font embedding flags. | 14:34.42 |
| | Hard to say really | 14:34.46 |
| Wolfram | Can't find "calibri"though when searching through the .ps | 14:35.14 |
| kens | Its probably in the font, which will be bainry and may be compressed | 14:35.51 |
| | binary* | 14:35.57 |
| | If you make the file avcailable somewhere I can look, but at the moment all I can really say is that we pretty much have to obey the laws here, and if its says 'no embedding' we have to do that. But the Windows font *I* have iisn't restrictied like that. | 14:36.58 |
| Wolfram | I'm also pretty sure that I don't have that problem on another Windows 10 PC | 14:38.06 |
| kens | With the same PostScript file ? | 14:38.18 |
| | That would seem 'odd' | 14:38.23 |
| | But again, I can't investigate without seeing the input file | 14:38.35 |
| Wolfram | I can try to generate a dummy doc... | 14:39.05 |
| kens | Any file which demonstrates the problem | 14:39.20 |
| Wolfram | Hm, .ps generated from newly created document *does* work with Calibri. Need to investigate further.... | 14:47.52 |
| kens | Possibly the document was created on a different system, one where Callibri is restricted | 14:48.36 |
| Wolfram | No, I created (printed to redirected port) it today -- but from an old document. Maybe that makes a difference??? | 14:50.03 |
| | Thanks for the moment. Will come back if I know better when the problem occurs | 14:50.53 |
| kens | Wolfram: I'll be happy to look at a PS file if it helps, but at present, there's not a lot I can say. Good luck | 14:52.24 |
| Wolfram | Ok, works now :-) I have a Calibri "Version 6.22, C 2018, Embeddability: Editable" and a "Version 6.12, C 2015, Embeddabiity: Restricted" on my system | 15:00.11 |
| kens | Huh, weird.... | 15:00.26 |
| Wolfram | I deinstalled and reinstalled the font today to make sure only the former one is used. However, because i was convinced, that the ps -> pdf conversion was the problem, I never re-created the .ps file. | 15:01.35 |
| kens | Ah, that would do it :-) | 15:01.59 |
| Wolfram | With a newly created .ps it work s now | 15:02.00 |
| | So, thanks a lot for making me aware that the problem was already in the .ps file!! | 15:03.27 |
| kens | NP happy to be able to help | 15:03.37 |
| chrisl | Wolfram: Well, you've done the real work! | 15:03.45 |
| Wolfram | ... but might have searched much longer without your help. | 15:04.23 |
| chrisl | kens: So.... bit of a brain fart for me on that colorspace/color commit earlier.... | 15:04.49 |
| kens | Oh.... | 15:04.58 |
| | It looked OK, what went wrong ? | 15:05.09 |
| chrisl | I forgot that setcolorspace will blow away the current color | 15:05.10 |
| kens | Oh yes, never thought of that. | 15:05.27 |
| chrisl | So it works fine in normal use, but not for the preview-latex thing | 15:05.40 |
| kens | <sigh> | 15:05.52 |
| chrisl | Thus: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=5ef3a531d00715c2b8bcfd38401515d4f60bfec5 | 15:06.07 |
| | Same operations, different order | 15:06.29 |
| kens | Yes that looks sensible | 15:07.00 |
| chrisl | It was one of those: just a small tweak, so small I don't need to retest.... sh*t :-( | 15:07.42 |
| kens | In the long tun we may want to keep a method to set the fill and stroke coloru and spaces from PostScript, so that people could use initgraphcis to set both | 15:08.13 |
| | But that's a logn way down the road yet | 15:08.31 |
| chrisl | Ideally, yes. | 15:08.33 |
| Nancy_iMac | kens: Transparency... I guess the device gets installed and then is meant to stay in the chain? It is somehow disabled by always there? | 15:12.08 |
| kens | Well, for regular devices there is no way to remove them once they are present, except by grestore back to a point prior to installation | 15:12.40 |
| Nancy_iMac | If that's the case, then the code I had written last week is mostly wrong. Probably the memory leak should be cleared up when the context is cleaned up, but otherwise the odd way the gsave/restore interacts with the device is probably intended? | 15:12.54 |
| kens | There is some kind of mechanism for disabling it, I don't recall what exactly, mvrhel_laptop can probably tell you more about that | 15:13.10 |
| | Hmm, not certain what you mean about the 'odd way...' | 15:13.41 |
| Nancy_iMac | I need to look at it all more carefully. But the basic thing I had found was that gsave increments the current device, and grestore decrements the current device (before doing the "restore") so in the case of transparency | 15:13.44 |
| | the base device gets incremented by the gsave, and then the pdf14 device gets decremented by the corresponding grestore | 15:14.05 |
| | to me that is just bonkers | 15:14.08 |
| kens | Well that doesn't look right to me I must confess | 15:14.24 |
| | The device ought to be decremented when its removed form the gstate | 15:15.10 |
| | And the newly emplaced device incremented | 15:15.19 |
| Nancy_iMac | If there's no hidden documentation I wasn't aware of, then I guess I will just have to study the code some more. I found like ~5 places that the pop/push functions are called, and none of those places do anything significantly different from the way the pdfi implementation was doing it, and apparently they don't have memory leaks | 15:15.27 |
| kens | Then the gsave/grestore woudl work correctly. That's what we are doing for the font in pdfi. | 15:15.37 |
| | I don't think there's much in the way of documentation, I could be wrong. Michael and/or Ray are the ones who know most about all this. | 15:16.16 |
| chrisl | Nancy_iMac: I'd look at what the XPS interpreter does, as a start. It won't rely on save/restore or gc memory | 15:16.26 |
| Nancy_iMac | chrisl: Yeah I have looked at that, and it didn't seem to do anything special. But I confress I have no idea how to run that code. | 15:16.48 |
| chrisl | An XPS file? | 15:17.04 |
| Nancy_iMac | I am just assuming it has no memory leaks | 15:17.10 |
| kens | I'm not certain that's a safe assumption :-) | 15:17.22 |
| Nancy_iMac | yeah, I don't know where/how the xps code is used. Hadn't looked into it | 15:17.24 |
| chrisl | Possibly a brash assumption :-) | 15:17.27 |
| kens | GhostXPS is the executable | 15:17.35 |
| | or gxps on Linux/Mac | 15:17.42 |
| | You need an XPS file of course, whcih you can easily make on Windows. I don't know if we ship any examples | 15:18.02 |
| | Apparently we don't | 15:18.18 |
| Nancy_iMac | yeah I would need an XPS file that has transparency. It's just an area I know 0 about | 15:18.20 |
| chrisl | An XPS file *with* opacity | 15:18.25 |
| kens | But there are some in the cluster tests | 15:18.27 |
| Nancy_iMac | (since it's windows... less than zero!) | 15:18.43 |
| kens | Hack the code to seg fault if it executes, run a cluster test | 15:18.47 |
| | THe the seg faultign files are the ones which exercise that code | 15:19.04 |
| Nancy_iMac | okay I can try that | 15:19.05 |
| chrisl | There are two XPS files in xps/tools/* but I doubt they use opacity | 15:19.06 |
| Nancy_iMac | okay I will see if I can find an xps example, and I will study the code more. | 15:19.57 |
| chrisl | FWIW, gs_pop_pdf14trans_device() should put the compositor into "passthrough" mode | 15:20.44 |
| Nancy_iMac | chrisl: Yeah, this "passthrough" thing is something I probably need to understand better | 15:21.13 |
| | it could be that everything is fine and I just need to add code in the context cleanup to decrement the transparency device, and then a miracle will occur | 15:21.38 |
| kens | is unconvinced | 15:22.14 |
| Nancy_iMac | I need to double-check some things from last week, such as exactly how many extra references are laying around during cleanup, etc. | 15:22.36 |
| | I am not sure if I went off on a tangent or not, with the way I was trying to solve it. | 15:22.51 |
| kens | Fair enough | 15:22.52 |
| Nancy_iMac | it is all a bit confusing because there are like 21 leaked blocks in my test file, but I think they all trace back to just needing to get the base and pdf14 device properly freed. | 15:23.24 |
| | But that wasn't obvious just from looking at the memento output | 15:23.38 |
| kens | I presume the compositr has a lot of stuff allocated | 15:23.48 |
| Nancy_iMac | so some tangents and side-tunnels happened | 15:23.56 |
| chrisl | Nancy_iMac: Also, remember that XPS, the only other user of the transparency compositor (so far), only uses a fraction of the code, so it's quite possible that there as PDF only features that still rely on the garbager to clean up | 15:24.27 |
| Nancy_iMac | dark, twisty passages, etc | 15:24.31 |
| chrisl | So, you may be finding real memory leaks | 15:24.41 |
| Nancy_iMac | chrisl: Yeah, anything is possible :) | 15:25.31 |
| chrisl | Just sayin': user error isn't the only possibilty here! | 15:26.19 |
| Nancy_iMac | heh heh | 15:26.37 |
| | anyway my goal at this point is a solution that doesn't require changes at the gs_XX_pdf14trans_device() level. I just don't want it to be too hacky | 15:27.16 |
| kens | That would be ideal | 15:27.31 |
| Nancy_iMac | kens: chrisl Thanks, this should keep me busy for a while :) | 15:29.09 |
| kens | Yeah well I'm off into text stuff, that'll keep me quiet for the forseeable | 15:29.27 |
| Nancy_iMac | :) | 15:29.43 |
| Wolfram | Just wanted to return briefly to also say Thank You for so many years of ghostscript maintenance first from ghostgum and now from Artifex. Over the last twenty years I have made some really fun stuff in postscript and none of it would have been possible without ghostscript (and psutils). I only hope that RedMon never ever breaks because I have seri | 18:34.45 |
| | ous doubts that Rusell will ever update it again :) | 18:34.45 |
| ata2001 | From the documentation: "The Ghostscript interpreter can be built as a dynamic link library" ... "With some changes, it could be built as a static library." | 19:50.29 |
| | Is it not possible to build it statically at the moment? | 19:50.58 |
| | What changes would be necessary? | 19:51.08 |
| | quoted page: https://www.ghostscript.com/doc/current/API.htm | 19:57.05 |
| | <<<Back 1 day (to 2019/07/01) | Forward 1 day (to 2019/07/03)>>> | |
Log of #ghostscript at irc.freenode.net.
