RE: [EXTERNAL] Re: Bug: tt_check_single_notdef function skip spaces

[Dominik Mazgaj]

Hi

Thank you for the quick reply.

I expressed myself wrong. I know about bitmaps, but in this file our software 
only needs to render (or get width - depend of scenario) a space.

This file is truncated, the original file comes from the customer and it is a 
bill with personal data (I cannot send it completely but is easier to debug).

Original producer: /Producer (Microsoft: Print To PDF)

I know it's tricky, I debugging already on the third day. I wanted to fix this 
on our side, but if we remove FT_FACE_FLAG_SCALABLE internally then I don't see 
the possibility of calculate the width of the scaled space for this font. I 
know it's a some kind of bad PDF, but Acrobat and Ghost Script can handle this 
file without any problems. Our software report error during calculating space 
width. If space are recognized correctly in tt_check_single_notdef, everything 
will work fine.

If you are not going to fix this, please give me some advice on how to modify 
the tt_check_single_notdef function to recognize empty glyphs?

Regards
Dominik Mazgaj

-----Original Message-----
From: Werner LEMBERG <wl@gnu.org> 
Sent: Tuesday, March 15, 2022 6:24 PM
To: Dominik Mazgaj <dominik.mazgaj@bluecrestinc.com>
Cc: freetype-devel@nongnu.org
Subject: [EXTERNAL] Re: Bug: tt_check_single_notdef function skip spaces


> I am attaching PDF with TrueType font, this font only has a space.
> The tt_check_single_notdef function ignores spaces, which removes the 
> FT_FACE_FLAG_SCALABLE flag.  In the next steps we want to scale this 
> font/empty glyph, but unfortunately we get the error that the font 
> cannot be scaled (that's not true).  The tt_check_single_notdef 
> function should be corrected so that it does not ignore spaces (a 
> blank glyph is also a glyph).

This is tricky.  The font in the PDF is not a font that 'only has a space'.  
Quite on the contrary, it contains *a lot* of non-empty glyphs, but not in the 
'glyf' table but as embedded bitmap strikes (via the 'EBDT' and 'EBLC' tables).

Having empty glyphs in the 'glyf' table and bitmap strikes are the only way to 
create bitmap-only fonts that can be displayed on Windows.[*] In other words, 
the font embedded in this PDF is *exactly* how a bitmap-only font looks like.  
FreeType must be able to handle them.

What PDF output engine has created this font?  If it should contain only 
spaces, why aren't the 'EBDT' and 'EBLC' tables stripped off?
Removing these two tables makes FreeType recognize the font as scalable.

My gut feeling says that I'm not going to change FreeType for this.


    Werner



[*] There are some additional conditions to make embedded bitmaps
    display on recent Windows versions that use 'DirectWrite' as the
    rendering engine, but this is off-topic.

This email message may contain confidential, proprietary and/or privileged 
information. It is intended only for the use of the intended recipient(s). If 
you have received it in error, please immediately advise the sender by reply 
email and then delete this message. No one other than the intended recipient 
may disclose, copy, distribute or use the information contained in this message.