>> Too bad that Microsoft's PDF driver doesn't strip off tables for >>embedded bitmaps. Maybe it makes even sense to write a bug report >>to MS: There shouldn't be any bitmap strikes in fonts part of a PDF. > > I can imagine a PDF where someone is using these bitmas in the right > size, but the space itself can be custom scaled .... And that won't > be a bug...
I don't think so: Bitmap strikes make *only* sense for screen display. As far as I know, there is normally no functionality to scale embedded bitmaps.[*] Bitmap fonts in PDFs are always Type 3 PS fonts. > Hmm, with my corporate email, I had trouble signing up here: > https://gitlab.freedesktop.org/groups/freetype/-/issues What exactly do you mean with 'signing up'? You need to register first before you can submit a Merge Request. If everything fails, an e-mail with the patch as an attachment will do, too. > sbits-always-scalable and FT_PARAM_TAG_SBITS_ALWAYS_SCALABLE. That > resolve this problem, but in my opinion problem is in > tt_check_single_notdef (don't see glyph at index 3). If I > understand correctly this function checking only glyph offsets > (empty glyph don't have different begin and end offset)? Correct. > I expected some corrections there. Acrobat and FontForge can see > that this is a (empty) glyph on index 3. The function works as expected, as far as I can see: If there are bitmap strikes but only space glyphs besides '.notdef', do not set 'FT_FACE_FLAG_SCALABLE' and handle the font as bitmap-only. As mentioned previously, this is (almost) the exact definition of how bitmap-only glyphs for Windows are constructed by FontForge (https://fontforge.org/docs/techref/bitmaponlysfnt.html). Werner [*] Well, there exists the `EBSC` OpenType table, but this is for screen display, too, and certainly not for PDF output.
