ANSIFontWriter::WriteWidths crashes about pdf-writer HOT 9 CLOSED

Agreed.
can you think of why the code tries to write the font?
[how is it aware of it at all?]

Gal.

from pdf-writer.

The font writing is occurring during EndPDF().

Our app is a PostScript->PDF converter. The converter does PDFWriter::GetFontForFile() when the PS program does a 'findfont,' but has no control over what the PS job will do with the font later -- if anything. Could be that the PS job only wants the font to read some information from it, or get text metrics, or get glyph outlines as paths instead of rendering them as text, or the PS could be defining a bunch of fonts just in case it needs them later. In any event, the PS program is in the driver's seat and the converter must deal with that.

We considered only doing GetFontForFile() on demand when the first text write occurs with that font, but that wouldn't work in the read-only scenarios enumerated above.

JD

from pdf-writer.

Got it. Ill have the code corrected so that only if the fint is actually used in writing (meaning - got glyphs) than representation is written.
Gimme a few days.
Thanks

from pdf-writer.

OK.
Essentially font definitions should not be written unless specific commands related to fonts are used (EncodeStringForShowing, EncodeStringsForShowing) so you should be safe with measures 'n such.

However, seems like there's a bug in hummus where if the text writing commands are used with empty strings there will be a failure as you describe.

I committed a correction to this. it's the latest commit.

Let me know if this fixes your issue. Otherwise we'll dig further.

Gal.

from pdf-writer.

No more exceptions thrown, but the fix gives us a PDF as below, which makes Acrobat Reader so unhappy that it won’t render the page. Ghostscript correctly renders the page with a warning that it had to repair errors. I'll bet the bad FN1 ref is the culprit.
<<
/Type /Page
/Parent 4 0 R
/MediaBox [ 0 0 432 144 ]
/Resources
<<
/ProcSet [ /PDF /Text ]
/Font
<<
/FN1 3435973836 0 R
>>
>>
/Contents 1 0 R

from pdf-writer.

yeah. looks like it.
I'm gonna need to know more about the usage. obviously something is being used in a way that i didn't expect and so far hasn't come up.

Do you think that you can construct a sample code that runs hummus that creates the problem?
Or send me that PDF that fails, that can help too. maybe i can figure this out through the content usage.

from pdf-writer.

Actually, i think that i simply need to remove the addition of font reference in case fonts are not being written.
think i got it, try the latest commit.

from pdf-writer.

Yup, you nailed it! THANK YOU.

from pdf-writer.

wonderful :)

from pdf-writer.