[EversonMono] Everson Mono FV test results
tiro at tiro.com
Fri Mar 13 03:43:22 GMT 2009
I am attaching the .xml format report from the MS Font Validator tool,
which I produced in response to Mark's Firefox-to-PDF bug report. If
you have access to a Windows machine, you can open the report in
Internet Explorer and, so long as the fval.xsl style sheet is in the
same directory as the report it should display in a convenient colour-
coded format; otherwise you can pop the .xml file open in a text
editor, but won't be able to determine which entries are errors,
warnings, passes or simply info.
Note that some error messages may be ignorable: Font Validator has
problems with non-BMP Unicode ranges in the OS/2 table, and may
incorrectly report whether such ranges are actually supported in the
cmap table. For instance, the report says that there are no Deseret
characters, but clearly there are.
There are a number of different kinds of errors in the font, including
a lot of glyphs with overlapping contours which FV treats as an error
(strongly discouraged might be a more accurate classification: some
RIPs have historically had problems with overlapping contours, and
some applications will incorrectly apply outlining to such glyphs).
The greatest number of errors, taking up most of the report, are
device metrics errors in the LTSH, VDMX and hdmx tables. This is a
common problem in FontLab-generated fonts, especially using Mac
FontLab for which there is no way to correct the problem. On Windows,
it is possible to set FontLab to run the MS cacheTT tool during font
generation, which correctly calculates device metrics. I can run
cacheTT on Everson Mono, if you like, and see if I can get rid of all
these problems. My guess is that the hdmx errors may be responsible
for the bug evident in Mark's PDF.
I see that in the font you have set the width of combining mark
characters to zero. This may make sense in a regular font, but it
causes problems in monospaced fonts. Once one declares a font to be
monospaced in various tables, it becomes problematic if *any* of the
glyphs have different widths. I doubt if this is going to cause very
significant difficulties for you, but it is worth knowing that the
recommended method in OpenType monospaced fonts is to set the width of
the combining marks to be the same as the other glyphs in the font,
and then to use the GPOS table to collapse the widths of the marks to
zero during positioning.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 324887 bytes
Desc: not available
More information about the EversonMono