cvs commit: xml-fop/src/documentation/content/xdocs/dev fonts.xml

2003-03-30 Thread vmote
vmote   2003/03/30 05:11:30

  Modified:src/documentation/content/xdocs/dev fonts.xml
  Log:
  Add more comments about AWT.
  
  Revision  ChangesPath
  1.2   +5 -3  xml-fop/src/documentation/content/xdocs/dev/fonts.xml
  
  Index: fonts.xml
  ===
  RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/dev/fonts.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- fonts.xml 20 Nov 2002 09:55:49 -  1.1
  +++ fonts.xml 30 Mar 2003 13:11:30 -  1.2
  @@ -24,8 +24,10 @@
 ul
   liWhy are we using our own font metric parsing and registration system, 
instead of the AWT system provided as part of Java?
 ul
  -liAnswer 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./li
  +liAnswer 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
   liAnswer 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
  +liAnswer 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
  +liAnswer 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
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



cvs commit: xml-fop/src/documentation/content/xdocs/dev fonts.xml book.xml

2002-11-20 Thread keiron
keiron  2002/11/20 01:55:49

  Modified:src/documentation/content/xdocs/dev book.xml
  Added:   src/documentation/content/xdocs/dev fonts.xml
  Log:
  new dev fonts.xml file to store some useful links and information
  about font work
  Submitted By: Victor Mote [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.6   +1 -0  xml-fop/src/documentation/content/xdocs/dev/book.xml
  
  Index: book.xml
  ===
  RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/dev/book.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- book.xml  19 Nov 2002 07:57:29 -  1.5
  +++ book.xml  20 Nov 2002 09:55:49 -  1.6
  @@ -21,6 +21,7 @@
   /menu
   menu label=Extras
 menu-item label=SVG href=svg.html/
  +  menu-item label=Fonts href=fonts.html/
   /menu
   menu label=Developers
 menu-item label=Design href=../design/index.html/
  
  
  
  1.1  xml-fop/src/documentation/content/xdocs/dev/fonts.xml
  
  Index: fonts.xml
  ===
  ?xml version=1.0 standalone=no?
  
  !-- $Id: fonts.xml,v 1.1 2002/11/20 09:55:49 keiron Exp $ --
  !DOCTYPE document PUBLIC -//APACHE//DTD Documentation V1.1//EN
  
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/document-v11.dtd;
  
  document
header
  titleFonts (Developer Information)/title
/header
body
  section
titleGoals/title
ul
  lirefactor existing font logic for better clarity and to reduce 
duplication/li
  liparse registered font metric information on-the-fly (to make sure most 
up-to-date parsing is used??)/li
  liresolve 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
  lihandle fonts registered at the operating system (through AWT)/li
  liadd support for parsing OpenType fonts/li
/ul
  /section
  section
titleIssues/title
ul
  liWhy are we using our own font metric parsing and registration system, 
instead of the AWT system provided as part of Java?
ul
  liAnswer 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./li
  liAnswer 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
/ul
  /li
/ul
  /section
  section
titleImplementation/title
pThere are two main font functions needed within FOP:/p
ul
  liprovision of a font object to be used in layout/li
  liembedding of a font file in output (such as PDF)/li
/ul
pFor 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
titleResources/title
section
  titleType 1 Fonts/title
  ul
lilink 
href=http://partners.adobe.com/asn/developer/pdfs/tn/T1_SPEC.PDF;Adobe Type 1 Font 
Format/link/li
liAccording 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
liFOP 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
lilink