Opened 15 years ago
Last modified 5 years ago
#87 new enhancement
Detect supported character sets of PFB fonts
Reported by: | Dmitry A. Kuminov | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | QtGui | Version: | 4.5.1 Beta 2 |
Severity: | low | Keywords: | |
Cc: |
Description
Currently, we report that standard OS/2 PFB fonts support all writing systems (aka scripts, or in other words, charsets) because I couldn't find an easy way to detect actually supported ones. The font itself seems to only specify that it supports "StandardEncoding" but in practice all .PFB fonts on my English OS/2 system only support "Latin1", "Cyrillic", "Greek" and "Hebrew" scripts.
Proper writing system detection is necessary to match fonts based on the requested writing system. For example, requesting for the "Japanese" WS causes all .PFB fonts to match the request although they don't contain Japanese symbols at all.
Change History (5)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
Severity: | → low |
---|---|
Type: | defect → enhancement |
comment:3 by , 7 years ago
A Type 1 font has an encoding field, as you have found, but the awkward thing about the Type 1 encoding format is that it supports a maximum of 256 mappings.
However, a Type 1 font can contain more than 256 actual characters even if it's not a CID-keyed (DBCS) font. I've investigated this in the past and am still not 100% sure how it's handled. It appears as though OS/2 Type 1 fonts use IsoLatin1Encoding for the first 256 glyphs, then encode the remaining characters using some fixed encoding that the OS/2 font engine understands. Part of the necessary information is probably included in the OFM (OS/2 specific Type 1 metrics) file for the font.
The IBM PSCRIPT printer driver sources in the DDK have some snippets of code for dealing with this, including some details of the OFM file format, but I've never managed to figure out the details of how it works.
I'd suggest assuming that Helvetica, Courier, Symbol and Times New Roman are the OS/2 versions, and use the OFM encoding system (if you can decipher how it works). Other fonts should just be assumed to use the 256-byte encoding they specify, unless you can find a standard somewhere that extends this.
comment:5 by , 5 years ago
is this still an issue with qt5? If yes we need to move the ticket.
dmik any thoughts?
Note that in r227 I've added a hack for "Workplace Sans" by Alex Taylor (http://users.socis.ca/~ataylo00/creative/fonts/) to make Qt think it supports more scripts than just Latin1 because it does indeed provides at least partial support for Cyrillic, Japanese and much more.