I am beginning to use Panose heavily to encourage systems to use the correct font for missing code points (based, in part, on Dave Crosby's posts on this forum).
Here's the question: If your document file (let's say we're talking MS Word .DOC/DOCX files) uses a font that is not on the authoring system, how does Word know the PANOSE signature of the missing font? This would be needed to find a suitable replacement font ...
Maybe the .DOC file format store the PANOSE signature of each font in the document, along with the name of the font?
Panose between Systems
Re: Panose between Systems
I don't know the how Word chooses a replacement font. From a person (me) who mainly does layout work, that it does so can be frustrating when bringing in manuscripts (when they are imported, there can be missing glyphs).
Word files in the past decade or so are a ZIP container. As regards text elements, these are contained in XML files. I don't remember ever seeing Panose information contained in these XML files. And there is no font information other than font names. So I suppose the how is actually coded into the .exe or associated DLLs.
Mike
Word files in the past decade or so are a ZIP container. As regards text elements, these are contained in XML files. I don't remember ever seeing Panose information contained in these XML files. And there is no font information other than font names. So I suppose the how is actually coded into the .exe or associated DLLs.
Mike
Re: Panose between Systems
I suspect that the sum total of planet-wide frustration with the pitfalls of auto-font selection in Word is massive (MS estimates 1.2 billion people use Word).
Designing a font collection to cover more than 65K code points is daunting. I am looking into using Panose values to emphatically nudge Word into selecting a specific font (i.e. the appropriate font in my font family). However, testing this is onerous ... so I thought I would ask here ...
Technical Sidetrip
My initial intent was to provide a glyph for every code point in every font, using (highly multi-mapped) fallback glyphs that indicated the font variant to use to obtain the real glyph for that code point.
Although it is unusual for a font to map every code point, this approach places control back into the hands of the author. The distinctive fallback characters would appear in the document to flag the “no glyph available” situation to the author, who can make a conscious choice about which font to use. This feature would only require a handful of glyphs in each font, and (I believe) completely address the set of Font Selection pitfalls inherent in Word.
However …
There is no cmap table format in the TrueType specification that serves this goal:
The format 12 table – the standard for Unicode fonts – balloons linearly with the number of assigned code points, and would require entries for approximately each of the potential Unicode code points (1,114,112) in every font.
Format 13 tables – intended for “Last Resort” fonts – use code point ranges for every glyph. This places a substantial overhead on each code point that is mapped to a distinct glyph in the font.
What is needed is a cmap table format that combines the features of format 12 and 13 tables. This new format table could use a flag field to indicate whether the code point range should be mapped onto a single glyph (as in format 13 tables) or a sequence of glyphs (format 12).
I personally believe that the strategy of having fonts assign every code point is valid in situations where you want to place the decisions of font selection for non-standard code points back into the hands of the author, rather than silently changing the font to one that the application deems “best”.
In place of the “glyph for every code point” approach, I am adopting a strategy for setting Panose values to shove Word into my preferred font selection.
Designing a font collection to cover more than 65K code points is daunting. I am looking into using Panose values to emphatically nudge Word into selecting a specific font (i.e. the appropriate font in my font family). However, testing this is onerous ... so I thought I would ask here ...
Technical Sidetrip
My initial intent was to provide a glyph for every code point in every font, using (highly multi-mapped) fallback glyphs that indicated the font variant to use to obtain the real glyph for that code point.
Although it is unusual for a font to map every code point, this approach places control back into the hands of the author. The distinctive fallback characters would appear in the document to flag the “no glyph available” situation to the author, who can make a conscious choice about which font to use. This feature would only require a handful of glyphs in each font, and (I believe) completely address the set of Font Selection pitfalls inherent in Word.
However …
There is no cmap table format in the TrueType specification that serves this goal:
The format 12 table – the standard for Unicode fonts – balloons linearly with the number of assigned code points, and would require entries for approximately each of the potential Unicode code points (1,114,112) in every font.
Format 13 tables – intended for “Last Resort” fonts – use code point ranges for every glyph. This places a substantial overhead on each code point that is mapped to a distinct glyph in the font.
What is needed is a cmap table format that combines the features of format 12 and 13 tables. This new format table could use a flag field to indicate whether the code point range should be mapped onto a single glyph (as in format 13 tables) or a sequence of glyphs (format 12).
I personally believe that the strategy of having fonts assign every code point is valid in situations where you want to place the decisions of font selection for non-standard code points back into the hands of the author, rather than silently changing the font to one that the application deems “best”.
In place of the “glyph for every code point” approach, I am adopting a strategy for setting Panose values to shove Word into my preferred font selection.
-
- Moderator
- Posts: 11158
- Joined: Fri Oct 04, 2002 12:41 am
- Location: Bilthoven, The Netherlands
- Contact:
Re: Panose between Systems
That is correct. This is further explained in the Word Binary File Format Specification:
https://docs.microsoft.com/en-us/opensp ... 170af7cc22
Look for Panose, SttbfFfn, and FFN.
Re: Panose between Systems
Wow! Fantastic. Exactly what I needed ... Thanks!