[sc34wg4] Re: COR3 issue: ST_PitchFamily

suzuki toshiya mpsuzuki at hiroshima-u.ac.jp
Wed Sep 23 18:29:23 CEST 2015


Hi,

In today's meeting, there was a suggestion to check
whether the different coverage of the optional
attributes of CT_TextFont (charset/panose/pitchFamily)
has any impacts in resolving the embedded font resource.

I made a set of testing files, and tested with MS Office
2010 and 2013 on Microsoft Windows. I attached my
testing files in 7z archive format - if you want me
to upload some sites, please let me know.

The results could be summarized very simply, the different
coverage of the attributes has no impact in Microsoft
Office 2010 and 2013. The tested files are:

01) referring & referred parts have charset only
02) referring & referred parts have panose only
03) referring & referred parts have pitchFamily only
04) referring & referred parts have charset+panose
05) referring & referred parts have panose+pitchFamily
06) referring & referred parts have charset+pitchFamily
07) referring parts have charset, referred part has panose+pitchFamily
08) referring parts have panose, referred part has charset+pitchFamily
09) referring parts have pitchFamily, referred part has charset+panose
10) referring parts have charset+panose, referred part has pitchFamily
11) referring parts have panose+pitchFamily, referred part has charset
12) referring parts have charset+pitchFamily, referred part has panose
13) referring & referred parts have no charset, panose nor pitchFamily

None of them caused the warning dialogue. So, I think
"different coverage of the optional attributes; charset/
panose/pitchFamily" is not the "inconsistent attribute".

--

In addition, I tried to check the relationship between OS/2
table's supported codepage coverage and "charset" attribute.
I expected that "charset" attribute should be one of the
supported codepages declared in ulCodePageRange in OS/2 table
of TrueType:

http://www.microsoft.com/typography/otspec/os2.htm#cpr

Modern Turkish is written by Latin script, so, Century and
Arial raise "Turkish" bit on, in OS/2 table. However, if I set
"charset" attribute to 161 (=Turkish), Office2010 complains
some resources in the document could not be opened. From this
result, it is not easy to describe how the charset is determined
from the given font bitstream. Some people may want further
clarification, but it would be long way (more experiments are
needed) and should not be dealt as a part of DR 09-0037.

Regards,
suzuki toshiya, Hiroshima University, Japan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DR09-0037_tests.7z
Type: application/octet-stream
Size: 1799881 bytes
Desc: not available
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20150924/395746e9/attachment-0001.obj>


More information about the sc34wg4 mailing list