| <<<Back 1 day (to 2019/03/19) | 20190320 |
kens | inkbottle (for the logs) that program uses several Ghostscript-specific internal operators, it won't work on any thing other than Ghostscript and fom the next version onwards, won't work on Ghostscript either. | 07:57.24 |
charliec | I have used the eps2write device to extract pages from a pdf into eps files. | 12:11.39 |
| I then utilised the eps files using the run operator in a postscript program. | 12:11.45 |
| When I print the postscript or render it to PDF using pdfwrite device, pages after the call to run are missing output for J,Q,V,Z. | 12:11.50 |
| The font used in the eps files are Helvetica and Helvetica-Bold and I am also using this font in the subsequent pages. | 12:11.57 |
| Any idea? | 12:12.01 |
| Sorry, version 9.26 64 bit windows - thank you! | 12:14.17 |
chrisl | There's a good chance that the font gets subset, and the subsets get reused, but are incompatible. | 12:16.52 |
| Of course, you start with a PDF, and end with a PDF - why bother? | 12:18.12 |
charliec | Please forgive my ignorance, but when I set the font in subsequent pages : /Helvetica findfont 14 scalefont setfont - I am not attempting to do anything clever with the font - should I not get the default set of characters? | 12:19.47 |
| I am attempting to print the original document with additional pages and media changes - the pdf stage is only for proofing really. | 12:20.49 |
chrisl | Well, it depends if the font is being embedded, and I can't remember what the eps2write behaviour is for that. If the font is embedded in the EPS output, then not, you generally get a subset, only including the glyphs actually used in the document | 12:21.20 |
| It's pretty hard to tell without seeing the origina PDF, *and* it's not really my area.... but the engineer who knows this stuff best isn't on here right now | 12:23.38 |
charliec | OK, so that embedded font overwrites whatever the original one is for the entire document after the first call to run? So the next time I select that font, I am getting the subset instead? The missing characters in my instance are actually used in the original document. | 12:24.37 |
| Thank you for your assistance so far, it is appreciated because this has left me scratching my head until it has become sore! | 12:25.29 |
chrisl | That's not how subsetting works, I don't have time to into it in depth on here. | 12:25.53 |
| First question: when you run the EPS files, do you bound them with a save/restore ? | 12:26.20 |
charliec | Yes, gsave and grestore | 12:26.38 |
chrisl | *NO* save/restore | 12:26.54 |
charliec | No. | 12:27.17 |
chrisl | Well, you should use save/restore - regardless of the font problem | 12:27.50 |
charliec | OK, thank you - I have just added this - same results though. | 12:29.56 |
chrisl | Are the fonts embedded in the original PDF? | 12:31.25 |
charliec | No | 12:33.15 |
chrisl | Okay. Do you know if the fonts end up embedded in the EPS files? | 12:33.42 |
charliec | I believe so - when I distill the eps directly with pdfwrite, Adobe shows the font as Embedded Subset - I also pulled this from the eps file whilst investigating: /CharSet(/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/R/S/T/U/W/X/Y/a/at/b/bar/c/colon/comma/d/e/eight/f/five/four/g/h/hyphen/i/k/l/m/n/nine/o/one/p/parenleft/parenright/period/r/s/seven/six/slash/space/sterling/t/three/two/u/v/w/x/y/zero)/FontFile 11 0 R>> | 12:36.10 |
chrisl | Okay, so one thing you could try would be to add to the command line that creates the EPS files: -c "<< /NeverEmbed [ /Helvetica /Helvetica-Bold ] >> setdistillerparams" -f <input file>.pdf | 12:38.56 |
| (where "<input file>.pdf" is your source PDF) | 12:39.18 |
charliec | Okay, so I tried that and the files match exactly (well excluding the creation date of course!) | 12:47.49 |
chrisl | So, my only other idea, I'm not 100% sure how to specify this..... trying using -dSubsetFonts=false on the command line for the EPS files. | 12:50.40 |
| But it might require: -c "<< /SubsetFonts false>> setdistillerparams" -f in.pdf | 12:51.27 |
| Otherwise, stick around, and the relevant engineer should be around in a hour or so | 12:53.37 |
charliec | Bingo - that now works as expected. Thank you very much for your help. | 12:54.51 |
chrisl | It will result in the EPS files being larger | 12:55.34 |
charliec | I noticed that - that's no problem in this instance. | 12:56.55 |
| Sorry to be a pain, but out of curiosity, is this expected behaviour? i.e. should subsequent pages use the subset specified by the eps, even when enclosed in calls to save gsave grestore restore? | 13:02.47 |
chrisl | No, not expected. But that area in (e)ps2write and pdfwrite is a morass of heuristics, so that type of issue is not unheard of | 13:05.07 |
| It also *might* be a limitation on the way our PDF interpreter works in such cases | 13:05.33 |
charliec | OK chrisl, thank you for your assistance today | 13:21.46 |
chrisl | charliec: NP | 13:22.19 |
i3v | kens, I'm sorry for bugging you again, but could you please comment https://bugs.ghostscript.com/show_bug.cgi?id=700746#c2 ? Is there something wrong with that version? | 15:27.17 |
kens | With what version ? | 15:27.44 |
i3v | The html code in my comment 2 | 15:27.59 |
kens | Oh, there's probably nothing wrong with it. | 15:28.09 |
i3v | The "proposed replacement" for the "note 6" | 15:28.11 |
kens | But I don't intend to replace it until we drop the old colour correction code | 15:28.31 |
| BTW deprecated is incorrect, teh correct spellign is deprecated | 15:29.13 |
| oops wrong way round | 15:29.22 |
| Yes there are typos | 15:29.27 |
i3v | But that version now describes both "new" and "old" versions | 15:29.35 |
kens | I don't plan to worry about them right now | 15:29.36 |
| Yeah and both are present, and can be selected | 15:29.45 |
| When I finally remove the 'old' code I'll rewrite hte docs | 15:30.00 |
| Probably for the release in September if I remember | 15:30.22 |
i3v | OK, my idea was to propose the version with the same information, just a bit more readable. | 15:31.09 |
kens | Nobody reads the documentation anyway :-) | 15:31.22 |
i3v | It's nice if you would replace it soon anyway... | 15:31.47 |
kens | When the colour coonversion code changes, I'll change the docs. | 15:32.05 |
i3v | OK | 15:32.14 |
| And one more thing, the https://bugs.ghostscript.com/show_bug.cgi?id=700819#c2 | 15:32.21 |
| Do you mean the following should produce an error: | 15:32.48 |
| > gswin64c -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -q -sOutputFile=%1_v20.pdf -c "<</ColorConversionStrategy /CMYK /ColorConversionStrategyForImages /CMYK /foofoo /barbar>> setdistillerparams" -f %1.pdf | 15:32.49 |
| ? | 15:32.53 |
kens | Well I didn't test it, I thought it might throw an error, but I didn't try it to se | 15:32.57 |
i3v | OK, so, do you think that deserves another bug report? :) | 15:34.17 |
kens | No point, there's almost certainly nothing I can do about it | 15:34.35 |
| Its a consequence of the way that we pass parameters to devices. I'm not going to defend it, I don't like it, but its what we've got. | 15:35.01 |
i3v | OK, I understand. Most questionable thing is that this potential pitfall is undocumented... | 15:39.10 |
chrisl | It *is* documented - that's how setdistillerparams works "If a key does not exist in the implementation of the Distiller application, Distiller ignores the key" | 15:41.47 |
kens | hadn't read that | 15:42.21 |
| Is that the distillerparams technical note ? | 15:42.32 |
chrisl | https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/distillerparameters.pdf | 15:42.48 |
kens | Yep, that's the document I meant | 15:43.09 |
| I think I may have a newer version somewhere though | 15:43.19 |
chrisl | But it follows the workings of setpagedevice, for example | 15:43.43 |
kens | True | 15:43.50 |
| Seems version 7 is the latest document, I guess Adobe didn't bother to update it after that. | 15:44.45 |
chrisl | Of course, the link given in the annotation saying the document has been superseded, doesn't exist...... | 15:44.46 |
kens | I don't think there really is a newer version | 15:45.02 |
chrisl | I don't think there's a new version of *that* document, but there's a completely new document covering much of the material | 15:46.18 |
kens | THis seems to be the newest version: | 15:46.22 |
| https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/PDFCreationSettings_v9.pdf | 15:46.22 |
chrisl | Anyway, the point is, we appear to have implemented setdistillerparams as Adobe specified it | 15:47.38 |
i3v | chrisl, kens, yep... that appear to be true. Although I was unable to find the same statement in the "_v9" doc, I've just did a quick test. It simply ignores "\foofoo" in "test.joboptions" | 16:16.28 |
kens | I guess we're compatible then | 16:16.59 |
i3v | Sorry, I've meant "/foofoo". | 16:17.22 |
| Yep, so, it turns out to be as-expected. OK, thank you both! | 16:18.00 |
| Forward 1 day (to 2019/03/21)>>> | |