[EversonMono] Everson Mono FV test results

John Hudson tiro at tiro.com
Fri Mar 13 03:43:22 GMT 2009

Dear Michael,

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.

Regards, John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EversonMono5.106-FVreport.zip
Type: application/x-zip-compressed
Size: 324887 bytes
Desc: not available
URL: <http://evertype.com/pipermail/eversonmono_evertype.com/attachments/20090312/253950e8/attachment.bin>

More information about the EversonMono mailing list