On 18 Feb 2002 09:01:50 - , [EMAIL PROTECTED] wrote:
keiron 02/02/18 01:01:50
Modified:docs/xml-docs/fop fonts.xml
Log:
some more font embedding info
...snip...x8...snip...x8...
+notep
+If you do not want the font embedded in the PDF then remove the
+embed-file attribute. The PDF will then contain text using
+the font with the font metrics and to view it properly the
+font will need to be installed where it is being viewed.
+/p/note
This feature does not work correctly when using any CIDFonts
because specified CIDFont's CMap is wrong.
When no font are embeded in PDF, the PDF viewer, such as
Adobe AcrobatReader, try to use the host operating system
installed font. Then character code is mapped to glyph data
by using CMaps through some steps. For more details, see
Adobe CMap and CID Font Files Specification Version 1.0
http://partners.adobe.com/asn/developer/pdfs/tn/5014.CMap_CIDFont_Spec.pdf
I explain and assume that the CIDFontType2 is used. I illustrate
with a simple figure below:
1st mapping2nd mapping
character code - CID - glyph data
CMap CIDFont
resource resource
In fact, a little more complicated mapping may be occured.
There are two kinds of mapping. The one is to map the character
code in PDF to CID and the another is to map the CID to glyph
data in the used font.
First, the 1st mapping is done. When generating PDF without
embedding any font, FOP currently use TrueType font's cmap
glyph id as character code. This information is contained
in the font metrics file.
The CMap that used at 1st mapping is specified at the Encoding
entry in the Type0 Font Dictionary (see PDF1.4 spec, 5.6.5 Type0
Font Dictionaries section, p.353).
There are many Encoding value as described in PDF1.4 spec.
(see 5.6.4 CMaps section, p.342). FOP uses Identity-H encoding
as fixed value. This is implemented in
org.apache.fop.render.pdf.fonts.MultiByteFont class.
The Identity-H encoding does not convert any character code into
CID. Therefore the mapped CID is equivalent with character code
(This code is the TrueType cmap glyph id).
Next, the 2nd mapping is peformed. This mapping is based on
CIDSystemInfo Dictionary (see PDF1.4 spec, 5.6.2 CIDSystemInfo
Dictionaries section, p.336).
For example, if the CID is Adobe-Japan1-2 character collection,
the CIDSystemInfo must specify:
/CIDSystemInfo /Registry (Adobe)/Ordering (Japan1)/Supplement 2
As mentioned above, the CID handled by FOP depends on each font.
Currently FOP specifies CIDSystemInfo dictionary as following:
/CIDSystemInfo /Registry (Adobe)/Ordering (UCS)/Supplement 0
This CIDSystemInfo does not the pre-registered one (For more
details about ToUnicode, see PDF1.4 spec, 5.9 ToUnicode CMaps
section, p.368).
If I remember correctly, this CIDSystemInfo is used with ToUnicode
CMaps in about FOP-0.18.0. In currently FOP, however, the feature of
ToUnicode is commented out. So, the 2nd mapping could now work
correctly (The generated PDF is not readable and is not viewable).
Thus this CIDSystemInfo is WRONG !!!
In my experimental investigation, the following CIDSystemInfo is
work correctly when no font embedding.
/CIDSystemInfo /Registry (Adobe)/Ordering (Identity)/Supplement 0
Since a few months ago, I knew this problem. However I did not
report this to here because my solution is experimental one.
I looked for some document that proved my solution. The CIDToGIDMap
in CIDFont dictionary (PDF1.4 spec, 5.6.3 CIDFonts section, p.339)
is most nearest, but the association of CIDSystemInfo are not
written there...
The value of the Ordering entry is also fixed and the getOrdering()
method is implemented org.apache.fop.render.pdf.fonts.MultiByteFont
class.
If FOP supports to generate PDF with no font embedding, I suggest
to use my represented CIDSystemInfo on current FOP's font handling
architecture.
Please check on your environment and point it out if you noticed
my misunderstanding or any mistakes :-)
Sorry if my english is bad.
Thanks.
---
Satoshi Ishigami VIC TOKAI CORPORATION
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
