User-directory fonts are not parsed on Windows

[a-ludi]

Lately, I ran into the problem of missing font glyphs. The missing glyphs are for default ASCII characters like 'I' or '9'. Which glyphs are missing depends on the selected font, e.g. 'I' is "missing" in Open Sans and '9' is missing in Helvetica. I tried debugging the thing but I only found out that the characters in question are not in the _charToGlyphMapping table.

Can you help? I attached the Open Sans TTF files from my system in case you want to try reproducing the bug.

[p0nce]

_charToGlyphMapping is filled by parsing cmap tables, but they are not very well documented and I don't remember where I first found the documentation for them. (I think it was an opentype or truetype offline spec edited by Microsoft).

cmap parsing is in there: https://github.com/AuburnSounds/printed/blob/master/font/printed/font/opentype.d#L629

Recently I added the encodingID == 0 part and I'm feeling it was probably wrong (it was to support the Symbol font) I advice you dump the platformID / encodingID of the cmap table in your wanted fonts.

[a-ludi]

I just realized the problem is more complex than this. A minimal example cannot reproduce the behavior. I am trying to identify the crucial step...

[a-ludi]

The bug was solved by updating from v1.0.5 to v1.1.1 . The bug can be reproduced in the older version:

#!/usr/bin/env dub
/+ dub.sdl:
    dependency        "printed:canvas" version="1.0.5"
+/
import printed.canvas;
import std.stdio : writeln;

void main() {
    auto renderer = new PDFDocument();

    with (renderer)
    {
        fontFace = "Open Sans";
        fontSize = 3.52777767;
        fontWeight = FontWeight.normal;
        fontStyle = FontStyle.normal;

        writeln(measureText("I").width);
    }
}

Some of the changes in the font handling must have fixed it.

[a-ludi]

I am sorry, but the issue is not resolved, yet. The new version just handles missing glyphs more gracefully. This leads to a messed up layout:

One thing I should mention is that in reality the glyphs are contained in the font, of course.

[p0nce]

Starting investigation about those badly parsed CMAP tables...

[p0nce]

The actual problem seems to be that (I assume you're using Windows) the folder with C:\Users\<user>\AppData\Local\Microsoft\Windows\Fonts is never explorer and the matched font is not Open Sans.

[p0nce]

You can workaround by installing Open Sans font "for all users" which will put the files in c:\windows\fonts

[p0nce]

hello @a-ludi this should be fixed in v1.1.2 => dub upgrade Let me know if you still have this trouble.

[a-ludi]

I am using Linux and the paths seems to be correct. The font only exists in one location on my computer and it is correctly rendered in the PDF. I guess that proves it is correctly found.

[a-ludi]

Again sorry. I had a workaround still in effect which caused the wrong layout. Now, it seems to work.

[p0nce]

Er, OK. May I close this issue?