1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
<?xml version="1.0" standalone="no"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<!-- $Id$ -->
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.3//EN" "http://forrest.apache.org/dtd/document-v13.dtd">
<document>
<header>
<title>FOP Development: Fonts</title>
<version>$Revision$</version>
</header>
<body>
<section>
<title>Goals</title>
<ul>
<li>refactor existing font logic for better clarity and to reduce duplication</li>
<li>parse registered font metric information on-the-fly (to make sure most up-to-date parsing is used??)</li>
<li>resolve whether the FontBBox, StemV, and ItalicAngle font metric information is important or not -- if so, parse the .pfb file to extract it when building the FOP xml metric file</li>
<li>handle fonts registered at the operating system (through AWT)</li>
<li>add support for parsing OpenType fonts</li>
</ul>
</section>
<section>
<title>Issues</title>
<ul>
<li>Why are we using our own font metric parsing and registration system, instead of the AWT system provided as part of Java?
<ul>
<li>Answer 1: Many of our customers use FOP in a so-called "headless" server environment -- that is, the operating system is operating in character mode, with no concept of a graphical environment. We need some mechanism of allowing these environments to get font information. Java 1.4 has a mechanism for dealing with headless environments, and this issue may be resolved when we require that as a minimum platform. However, there may be an issue then of how to get fonts registered at the operating system in these environments. That will probably at least require some documentation for users.</li>
<li>Answer 2: At some level, we don't yet fully trust AWT to handle fonts correctly. There are still unresolved discrepancies between the two systems.</li>
<li>Answer 3: In the AWT mechanism, there does not appear to be a way to find the physical font file associated with an AWT font, or to otherwise get access to its contents so that it can be embedded in FOP output.</li>
<li>Answer 4: The Java 1.4 javadocs state (in java.awt.Font): "All implementations of the Java 2 platform must support TrueType fonts; support for other font technologies is implementation dependent." We wish to provide a greater base of font technologies for our users.</li>
</ul>
</li>
</ul>
</section>
<section>
<title>Implementation</title>
<p>There are two main font functions needed within FOP:</p>
<ul>
<li>provision of a font object to be used in layout</li>
<li>embedding of a font file in output (such as PDF)</li>
</ul>
<p>For the first of these, we will implement something along the lines of a "Facade" Structural Pattern to hide the differences between the various font types and font sources from the rest of the system.
Public classes will consist of TypeFaceFamily, TypeFace, and Font. (TypeFace roughly corresponds to the contents of a normal font file, while Font is a general typeface implemented at a specific point size, and perhaps with other specific parameters).
When another part of FOP requests a font object, existing font objects will be checked first, and an appropriate one returned if possible.
If not, the Font logic should resolve the TypeFace and TypeFaceFamily if possible, create a Font object, and return it.</p>
</section>
<section>
<title>Resources</title>
<section>
<title>Type 1 Fonts</title>
<ul>
<li><link href="http://partners.adobe.com/asn/developer/pdfs/tn/T1_SPEC.PDF">Adobe Type 1 Font Format</link></li>
<li>According to the Adobe web site, the documentation for the font metrics files (.pfm = printer font metrics) is written and controlled by Microsoft, since it is actually a workaround to allow Type 1 fonts to be used on a GUI screen in Windows. However, the document does not appear to be on the Microsoft web site. The best resource for this information is <link href="http://partners.adobe.com/asn/developer/pdfs/tn/5178.PFM.pdf">Adobe Technical Note #5178</link>: Building PFM Files for Postscript-Language CJK Fonts</li>
<li>FOP does not currently use the Adobe Font Metrics file, but the specification can be found in <link href="http://partners.adobe.com/asn/developer/pdfs/tn/5004.AFM_Spec.pdf">Adobe Technical Note #5004</link>: Adobe Font Metrics File Format Specification</li>
<li><link href="http://partners.adobe.com/asn/developer/pdfs/tn/5040.Download_Fonts.pdf">Adobe Technical Note #5040</link>: Supporting Downloadable Postscript Language Fonts may also include some useful information.</li>
</ul>
</section>
<section>
<title>TrueType Fonts</title>
<ul>
<li>The <link href="http://www.microsoft.com/typography/tt/ttf_spec/ttspec.zip">TrueType specification</link></li>
</ul>
</section>
<section>
<title>OpenType Fonts</title>
<ul>
<li>The <link href="http://download.microsoft.com/download/Typography/archive/v1.4/WIN98MeXP/EN-US/otsp14.exe">OpenType specification</link></li>
<li>The Adobe <link href="http://www.adobe.com/type/opentype/main.html">Introduction to OpenType fonts</link> page has some useful general information and links.</li>
</ul>
</section>
</section>
</body>
</document>
<!-- Last Line of $RCSfile$ -->
|
