| | <<<Back 1 day (to 2018/05/21) | 20180522 |
| kens | chrisl you there ? | 07:38.20 |
| chrisl | kens: yeh | 07:38.29 |
| kens | Is there any assumption that, in a CIDFont, CID 0 maps to the .notdef glyph ? | 07:38.50 |
| chrisl | That's a requirement, IIRC | 07:39.10 |
| kens | Hmm, OK. then that bug report is really valid. | 07:39.26 |
| chrisl | Yeh: "The default notdef character is always accessed by CID 0." | 07:41.33 |
| kens | You must be reading a different bit of the spec to me :-) | 07:41.49 |
| | ah yeah page 51 | 07:42.19 |
| | I was looking at 14 | 07:42.23 |
| chrisl | Well, then it goes on to say: "However, a developer can assign valid input codes to the default notdef character and to notdef characters other than the default." | 07:42.31 |
| | So, not a requirement, then... god I hate that spec :-( | 07:42.58 |
| kens | I'm not even sure I understand what that sentence means. | 07:43.09 |
| | OK so you can use the .notdef from places other than CID 0 | 07:43.54 |
| | But basically the default is always 0 | 07:44.11 |
| chrisl | Actually, that's rather confusing..... | 07:44.29 |
| kens | Yeah I think the sentence is confusingly worded | 07:44.45 |
| chrisl | It's talking about "input codes", not CIDs | 07:45.09 |
| kens | I know, but it is clear that CID 0 is always hte .notdef | 07:45.37 |
| chrisl | Right, Page 13 in the 5014 spec is what we want | 07:45.52 |
| | "The CID index value of 0 is always used to refer to the character meaning âthe undefined or ânotdefâ character.â This CID is used when the CMap file does not explicitly indicate a mapping for a character code." | 07:46.23 |
| kens | Exactly | 07:46.48 |
| | So back to the original 75 page example file (75 pages, really ?) | 07:47.07 |
| chrisl | You could just punt it back, and ask for a smaller example | 07:47.32 |
| kens | I was tempted, but it does look like a real problem. Possibly one we actually can't fix | 07:47.54 |
| | But to figure that out, I need to start from the original file | 07:48.05 |
| | I'll just see if I can reduce it with Acrobat | 07:48.18 |
| | Oh joy, I can't extract the page because the file is password protected. Now it really is going to be sent back | 07:49.14 |
| chrisl | I think I'm ready for more coffee.... | 07:53.42 |
| kens | hasn't had any yet :-( | 07:53.53 |
| chrisl | Crikey, that's brave..... | 07:54.05 |
| kens | It does look 'possible' that pdfwrite is re-encoding the CID to a base of 0. But realistically the file is too large, so I'm sending it back to the reporter. | 07:55.33 |
| | I'm also quite suspicious they are using GS illegally, but I can't bbe certain | 07:55.52 |
| | Well, that was quick :-) | 08:20.00 |
| | OK so the original input file uses CID 0, which is why our output uses CID 0. I don't think there's anything I can do about that, except abort teh PDF/A conversion. I'll check a little further first though. | 08:33.52 |
| chrisl | Couldn't you just drop the input codes that map to CID 0? | 08:35.06 |
| kens | I'd haev to remap them, or the text woudl go missing | 08:35.28 |
| chrisl | Oh, CID is marking? That's just bad | 08:35.51 |
| | CID 0 is marking, I should say | 08:36.00 |
| kens | I believe that the CID 0 is a marking glyph, though I admit I'm not yet certain | 08:36.12 |
| | Still reducing the file he sent that I cna actually work with | 08:36.28 |
| | Oh and its Apple's Quartz PDF Context which made these excellent files. | 08:39.54 |
| | OK seems the application is using CID 0 for a space. | 08:46.53 |
| | chrisl got a minute ? | 10:36.47 |
| chrisl | kens: sure | 10:39.13 |
| kens | Looking at this inkcov problem | 10:39.19 |
| | I think there's a real dichotomy | 10:39.27 |
| chrisl | Oh :-( | 10:39.31 |
| kens | The {%%Page: 1) comes from the PostScirpt job, one problem is that it is sent *after* the showpage, so its never going to prcede the ionkcov output | 10:39.54 |
| | More of a problem is the fact this its sent to 'stdout' | 10:40.08 |
| | Now thatt's the *interpreter* stdout | 10:40.15 |
| | Which is maintained as a stream in the interpreter context. | 10:40.25 |
| | When we get to the inkcov output code, it writes directly to the FILE * stdout | 10:40.37 |
| | So if there's buffered data in the interpreter stream, it doesn't get sent until 'later' | 10:40.53 |
| | Potentially, much later | 10:40.59 |
| chrisl | Er, isn't the stdout stream in the library context? | 10:41.01 |
| kens | No | 10:41.05 |
| | Well, not the same stream | 10:41.09 |
| | The one in the interpreter context is where the PostScript stdou goes to | 10:41.25 |
| | When that gets full, it gets flushed | 10:41.34 |
| | and it gets flushed to the sdtout in the library context | 10:41.46 |
| | So inkcov only sees the library context, so it can't tell the interpreter to flush its stdout | 10:42.04 |
| | I don't really know what to do about that :-( | 10:42.51 |
| | I could redefine '=' so it always flushes on every wrtie | 10:43.08 |
| | Perhaps hte best solution is for the reporter to include a PostScript fragment which does that redefinition if they want to output the inkcov results to stdout. | 10:44.41 |
| chrisl | God, that just seems broken to me - why do we need two lots of buffering? | 10:46.06 |
| kens | Umm, dunno ? | 10:46.20 |
| | To be honest, right at the moment I'm inclined to close this with a 'yeah that's the way PostScript works' and a suggestion as to how to solve it with a redefinition of = | 10:49.13 |
| | Because he's going to run into more problems with files that send stuff to stdout | 10:49.28 |
| chrisl | I think that's the only real option. | 10:49.42 |
| kens | OK then I'll do that, I wanted a second opinion though, in case I was being dumb | 10:50.14 |
| chrisl | The only other option would be for us to add a command line option for unbufferred stdout/stderr | 10:51.03 |
| kens | Yeah I thought about that, but its yet another command line option :-( | 10:51.19 |
| | Also it won't help him with other files which send stuff to stdout (eg the CET fiels) | 10:51.33 |
| | And besides, the interleaving of the page number is shall we say, confusing ? | 10:51.50 |
| | I thought I'd point out he could elminate thos altogether along with any other extrabeous stuff | 10:52.06 |
| | Hmm, but my code doesn't work as expected, it eats all the %%Page outptu odd. | 10:52.59 |
| chrisl | I wonder if the interpreter buffering of stdout actually makes *any* difference | 10:53.20 |
| kens | To performance ? I doubt it | 10:53.30 |
| chrisl | Considering we write to a FILE * with its own buffering | 10:53.49 |
| kens | Yeop | 10:53.59 |
| | OK fixed my redefinition, had a typo | 10:54.11 |
| | Lets make it eat '=' now instead | 10:54.29 |
| chrisl | Although, in theory, we do support writing to a descriptor as well | 10:54.43 |
| kens | In the PS interpreter ? | 10:55.03 |
| chrisl | Everywhere | 10:55.21 |
| kens | Oh, didn't know that | 10:55.28 |
| chrisl | I bet it doesn't work..... | 10:55.34 |
| kens | :-) | 10:55.38 |
| chrisl | At build time change FILE_IMPLEMENTATION from "stdio" to "fd" | 10:56.02 |
| kens | Hmmmmm | 10:56.25 |
| | Not even going to suggest a build time option :-) | 10:56.35 |
| chrisl | Course, it won't stop the device interface from using FILE * - doh! | 10:56.57 |
| | On that basis, we should probably kill that option | 10:57.29 |
| kens | I think that's reasonable, bet nobody knows about ti anyway | 10:58.07 |
| chrisl | In fact, it still uses FILE * anyway, it just gets the descriptor from teh FILE * and then uses it. What a waste of time/space/effort.... etc, etc | 10:59.10 |
| kens | Emm yes, that does seem wholly pointless | 10:59.25 |
| chrisl | I'd guess it was to work around some long dead bug in the C lib | 11:00.03 |
| maxter | hi everybody | 15:42.57 |
| | i need deploy ghostpcl6 in debian 8, how? | 15:43.58 |
| kens | 2 choices: locate the relevant package and use your favourite package management tool | 15:44.32 |
| | download the source code form our website and build it yourself | 15:44.45 |
| chrisl | maxter: You need to be aware of the license conditions of both the code *and* the fonts - the PCL fonts are under a non-GPL compatible license | 15:46.05 |
| maxter | with the binaries can do something? | 15:46.44 |
| chrisl | The binaries are really only for basic testing, for a proper deployment you should build from source | 15:47.25 |
| maxter | ok thanks a lot | 15:47.39 |
| | Forward 1 day (to 2018/05/23)>>> | |
Log of #ghostscript at irc.freenode.net.