You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by "J.U. Anderegg" <ha...@bluewin.ch> on 2003/04/16 10:43:12 UTC
Renderer Programming
is shooting at a moving target, at least with FOP releases 0.20.x. The
AbstractRenderer is formally stable, but you are hardly able to tell how
areas and area fields relate to XSL inputs. Is the geometry of areas
documented anywhere: border and line stroke width, paddings included,
half-inlcuded or excluded, which coordinates the renderer gets?
The AWT and my JPS renderer need
- All pages accessible at any time, to view and print selected pages. Will a
word still take about 1KB memory in the new design?
- PDF renderer classes: what for?
- Font metrics: that's business of the formatter, the renderer might have to
deal with physical fonts.
Java Graphics2D (text, fonts) does lots of things much better, easier and
most likely more efficently than present FOP. Regarding the new design there
is a choice:
- a home grown PDF program: forever limited function
- a Java system, which might not fulfill the cute wishlist of XSL specs
What are the new design decisions?
Hansuli Anderegg
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: How layout works
Posted by Victor Mote <vi...@outfitr.com>.
Hansuli Anderegg wrote:
> I develop with Windows.
>
> > What mechanism are you using to actually get the PDF built?
>
> The Java Printing System feeds printer drivers. The PDFWriter of
> Acrobat 5.0
> is a printer driver under Windows. Select the driver option
> 'print to file'
> by the program.
OK, so you are thinking of this as a Windows-only, interactive-only FOP
add-in instead of a general enhancement for FOP? I thought you were headed
toward a more general solution.
> > I was especially
> > troubled by the fact that Java doesn't seem to even give the
> > ability to find
> > the physical location of the font files so that they can be
> > embedded.
>
> So easy, e.g. to list available fonts:
>
> GraphicsEnvironment gEnv = GraphicsEnvironment.
> getLocalGraphicsEnvironment();
> String[] localFonts = gEnv.getAvailableFontFamilyNames();
> log.debug("available fonts: ");
> for (int i = 0; i < localFonts.length; i++) {
> log.debug("" + localFonts[i]);
> }
That's not what I asked. For a general FOP solution, if you're going to use
AWT fonts, you need to be able to embed them. Java gives me lots of
information about them, but not the location of the font file itself, as far
as I can tell.
> Look into Java's font properties.
I've spent a lot of time doing that -- never have found the one I need.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
AW: How layout works
Posted by "J.U. Anderegg" <ha...@bluewin.ch>.
> Victor Mote wrote:
>
> I have been interested in taking more advantage of the Java 2D tools, but
> there was one thing that seemed to kill the idea for me: the
> renderer.
The renderer I'm working on is a redesign of the AWT renderer/viewer - a
migration to Java 1.4. The code is restructured, cleaned as far as FOP
allows it.
- upgrade font processing to Java 1.4
- use Image I/O
- use Batik 1.5 with a new transcoder
- Java Printing System:
o use the properties, settings of printer drivers
o use Print Request AttributeSets of Java Printing System: allows silent
printing, media control
- add page caching
I develop with Windows.
> What mechanism are you using to actually get the PDF built?
The Java Printing System feeds printer drivers. The PDFWriter of Acrobat 5.0
is a printer driver under Windows. Select the driver option 'print to file'
by the program.
> I was especially
> troubled by the fact that Java doesn't seem to even give the
> ability to find
> the physical location of the font files so that they can be
> embedded.
So easy, e.g. to list available fonts:
GraphicsEnvironment gEnv = GraphicsEnvironment.
getLocalGraphicsEnvironment();
String[] localFonts = gEnv.getAvailableFontFamilyNames();
log.debug("available fonts: ");
for (int i = 0; i < localFonts.length; i++) {
log.debug("" + localFonts[i]);
}
Look into Java's font properties.
The debug log shows what the renderer accesses on the platform.
Hansuli Anderegg
----------------------------------------------------------------------------
---------
[DEBUG] ------------------------------------------------------------
[DEBUG] time: startRenderer --- interval 0 memory used: 1074Kb
[DEBUG] ------------------------------------------------------------
[DEBUG] available fonts:
[DEBUG] Agency FB
[DEBUG] Algerian
[DEBUG] Arial
[DEBUG] Arial Black
[DEBUG] Arial MT
[DEBUG] Arial Narrow
[DEBUG] Arial Rounded MT Bold
[DEBUG] Arial Unicode MS
[DEBUG] BARcode2D
[DEBUG] Baskerville Old Face
[DEBUG] Batang
.
[DEBUG] Wingdings
[DEBUG] Wingdings 2
[DEBUG] Wingdings 3
[DEBUG] ------------------------------------------------------------
[DEBUG] Available Print Services
[DEBUG] Symantec Fax Starter Edition
[DEBUG] IBM AFP 240
[DEBUG] hp psc 700 series
[DEBUG] HP LaserJet 5M
[DEBUG] HP LaserJet 4/4M PS
[DEBUG] Generic / Text Only
[DEBUG] Fax
[DEBUG] Acrobat PDFWriter
[DEBUG] Acrobat Distiller
[DEBUG] ------------------------------------------------------------
[DEBUG] ------------------------------------------------------------
[DEBUG] Attributes set:
[DEBUG] ------------------------------------------------------------
[DEBUG] Printer name is: Acrobat PDFWriter
[DEBUG] No. of Print Service attribute categories are 13
[DEBUG] Supported Print Service attribute categories are:
[DEBUG] class javax.print.attribute.standard.JobName
[DEBUG] Java Printing
[DEBUG] ------------------------------------------------------------
[DEBUG] class javax.print.attribute.standard.RequestingUserName
[DEBUG] Administrator
[DEBUG] ------------------------------------------------------------
[DEBUG] class javax.print.attribute.standard.Copies
[DEBUG] 1
[DEBUG] ------------------------------------------------------------
[DEBUG] class javax.print.attribute.standard.Destination
[DEBUG] file:/C:/FOPApps/JPS0.2/out.prn
[DEBUG] ------------------------------------------------------------
[DEBUG] class javax.print.attribute.standard.OrientationRequested
[DEBUG] landscape
[DEBUG] reverse-landscape
[DEBUG] ------------------------------------------------------------
[DEBUG] class javax.print.attribute.standard.PageRanges
[DEBUG] ------------------------------------------------------------
[DEBUG] class javax.print.attribute.standard.Media
[DEBUG] na-legal
[DEBUG] tabloid
[DEBUG] iso-a4
[DEBUG] iso-a3
[DEBUG] executive
[DEBUG] jis-b4
[DEBUG] jis-b5
[DEBUG] top
[DEBUG] ------------------------------------------------------------
[DEBUG] class javax.print.attribute.standard.MediaPrintableArea
[DEBUG] (6.35,6.35)->(203.2,342.9)mm
[DEBUG] (6.35,6.35)->(266.7,419.1)mm
[DEBUG] (6.35,6.35)->(197.273,284.311)mm
[DEBUG] (6.35,6.35)->(284.311,407.331)mm
[DEBUG] (6.35,6.35)->(171.45,254.0)mm
[DEBUG] (6.35,6.35)->(237.321,340.275)mm
[DEBUG] (6.35,6.35)->(169.333,244.263)mm
[DEBUG] ------------------------------------------------------------
[DEBUG] class javax.print.attribute.standard.Fidelity
[DEBUG] true
[DEBUG] ------------------------------------------------------------
[DEBUG] class sun.print.SunAlternateMedia
[DEBUG] alternatate-media: iso-a4
[DEBUG] ------------------------------------------------------------
[DEBUG] class javax.print.attribute.standard.Chromaticity
[DEBUG] ------------------------------------------------------------
[DEBUG] class javax.print.attribute.standard.SheetCollate
[DEBUG] ------------------------------------------------------------
[DEBUG] class javax.print.attribute.standard.PrinterResolution
[DEBUG] 15000x15000 dphi
[DEBUG] 30000x30000 dphi
[DEBUG] 60000x60000 dphi
[DEBUG] ------------------------------------------------------------
[DEBUG] used fonts:
[DEBUG] sans-serif/normal/normal/24 -->
java.awt.Font[family=Arial,name=Arial,style=plain,size=24], platform: Arial
[DEBUG] sans-serif/normal/normal/17 -->
java.awt.Font[family=Arial,name=Arial,style=plain,size=17], platform: Arial
[DEBUG] sans-serif/normal/normal/10 -->
java.awt.Font[family=Arial,name=Arial,style=plain,size=10], platform: Arial
[DEBUG] sans-serif/normal/normal/8 -->
java.awt.Font[family=Arial,name=Arial,style=plain,size=8], platform: Arial
[DEBUG] sans-serif/normal/bold/14 -->
java.awt.Font[family=Arial,name=Arial,style=bold,size=14], platform: Arial
Fett
[DEBUG] sans-serif/normal/normal/16 -->
java.awt.Font[family=Arial,name=Arial,style=plain,size=16], platform: Arial
[DEBUG] sans-serif/normal/normal/12 -->
java.awt.Font[family=Arial,name=Arial,style=plain,size=12], platform: Arial
[DEBUG] sans-serif/normal/normal/18 -->
java.awt.Font[family=Arial,name=Arial,style=plain,size=18], platform: Arial
[DEBUG] sans-serif/italic/normal/12 -->
java.awt.Font[family=Arial,name=Arial,style=italic,size=12], platform: Arial
Kursiv
[DEBUG] sans-serif/italic/bold/12 -->
java.awt.Font[family=Arial,name=Arial,style=bolditalic,size=12], platform:
Arial Fett Kursiv
[DEBUG] sans-serif/normal/normal/9 -->
java.awt.Font[family=Arial,name=Arial,style=plain,size=9], platform: Arial
[DEBUG] sans-serif/normal/normal/20 -->
java.awt.Font[family=Arial,name=Arial,style=plain,size=20], platform: Arial
[DEBUG] sans-serif/italic/normal/28 -->
java.awt.Font[family=Arial,name=Arial,style=italic,size=28], platform: Arial
Kursiv
[DEBUG] sans-serif/normal/normal/28 -->
java.awt.Font[family=Arial,name=Arial,style=plain,size=28], platform: Arial
[DEBUG] sans-serif/normal/bold/24 -->
java.awt.Font[family=Arial,name=Arial,style=bold,size=24], platform: Arial
Fett
[DEBUG] sans-serif/normal/normal/21 -->
java.awt.Font[family=Arial,name=Arial,style=plain,size=21], platform: Arial
[DEBUG] monospace/normal/normal/12 --> java.awt.Font[family=Courier
New,name=Courier New,style=plain,size=12], platform: Courier New
[DEBUG] monospace/normal/bold/10 --> java.awt.Font[family=Courier
New,name=Courier New,style=bold,size=10], platform: Courier New Fett
[DEBUG] sans-serif/normal/normal/14 -->
java.awt.Font[family=Arial,name=Arial,style=plain,size=14], platform: Arial
[DEBUG] sans-serif/italic/normal/14 -->
java.awt.Font[family=Arial,name=Arial,style=italic,size=14], platform: Arial
Kursiv
[DEBUG] sans-serif/normal/bold/16 -->
java.awt.Font[family=Arial,name=Arial,style=bold,size=16], platform: Arial
Fett
[DEBUG] monospace/normal/bold/12 --> java.awt.Font[family=Courier
New,name=Courier New,style=bold,size=12], platform: Courier New Fett
[DEBUG] sans-serif/normal/bold/12 -->
java.awt.Font[family=Arial,name=Arial,style=bold,size=12], platform: Arial
Fett
[DEBUG] monospace/normal/normal/13 --> java.awt.Font[family=Courier
New,name=Courier New,style=plain,size=13], platform: Courier New
[DEBUG] sans-serif/normal/bold/21 -->
java.awt.Font[family=Arial,name=Arial,style=bold,size=21], platform: Arial
Fett
[DEBUG] monospace/normal/bold/14 --> java.awt.Font[family=Courier
New,name=Courier New,style=bold,size=14], platform: Courier New Fett
[DEBUG] ------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: How layout works
Posted by Victor Mote <vi...@outfitr.com>.
J.U. Anderegg wrote:
> A very attractive idea! Some notes follow on how much Java does in
> formatting.
...
> o Java supports fonts (TTF, OPI), text formatting, and Unicode well (is
> there correct Arabic, Hebrew bidi in the attached PDF?). There are system
> functions to access platform fonts, metrics and formatting functions too.
> Forget font metric files - embedding fonts is the job of the PDF renderer.
...
> A minimal, complete renderer
...
> This is all what it ends up to. Of course there are some
> intermediate stages
> from FO's to the renderer interface.
I have been interested in taking more advantage of the Java 2D tools, but
there was one thing that seemed to kill the idea for me: the renderer. What
mechanism are you using to actually get the PDF built? I was especially
troubled by the fact that Java doesn't seem to even give the ability to find
the physical location of the font files so that they can be embedded. If you
have solved this problem, I am VERY interested. I just reread your April 16
post on the topic, and I guess I was confused by what it was telling /
asking, but when I put it together with this one, I think I understand. If
you can clarify what renderer you are talking about (yours? FOPs interface?
Java2D?), I would definitely like to pursue this further.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
AW: How layout works
Posted by "J.U. Anderegg" <ha...@bluewin.ch>.
> Victor Mote wrote:
> On #5, I have just recently decided that I liked the idea of the layout
> managers totally separate from the FO Tree.
> I'd like for layout to be pluggable, and keeping the LMs separate
> would seem to facilitate that. Don't like FOP's layout? Drop in your own.
A very attractive idea! Some notes follow on how much Java does in
formatting.
_______________________________________________________________
o Graphics2D provides the objects to present and process data used by
formatters.
o Java's Image I/O: a few statements do the job.
o Java supports fonts (TTF, OPI), text formatting, and Unicode well (is
there correct Arabic, Hebrew bidi in the attached PDF?). There are system
functions to access platform fonts, metrics and formatting functions too.
Forget font metric files - embedding fonts is the job of the PDF renderer.
o Have JTable process sophisticated tables?
o My renderer/viewer (and the AWT renderer) need random access to all pages
at printing and viewing time. The renderer is going to cache pages. Images
and external SVG's are loaded on demand. Memory usage seems to be
acceptable.
o The AWT viewer is a well-done piece of software. Memory problems stem from
FOP memory usage.
_______________________________________________________________
A minimal, complete renderer
- The interface specifies very few methods as sketched below
- The renderer draws, paints graphics - these are not FO's rendering
themselves.
-----------------------------------------------------------
Page(float x, float y, float width, float height)
- x, y: left/top offset
-----------------------------------------------------------
SVG(String source, float x, float y, float width, float height, double dpi)
- source: external graphic or instream-foreign-object
-----------------------------------------------------------
Image(String source, float x, float y, float width, float height, double
dpi)
-----------------------------------------------------------
Line(float x1, float y1, float x2, float y2, BasicStroke stroke,
Color strokeColor)
-----------------------------------------------------------
Rectangle(float x, float y, float w, float h, Color fillColor)
-----------------------------------------------------------
Text(String word, Map attributeMap, float x, float y, Color color)
- attributeMap: font, underline, overstrike, ...
-----------------------------------------------------------
PDF only:
Link
-----------------------------------------------------------
- Accessibility will have to put more info into renderer objects.
- The methods are listed in drawing sequence priority.
-----------------------------------------------------------
This is all what it ends up to. Of course there are some intermediate stages
from FO's to the renderer interface.
_______________________________________________________________
Hansuli Anderegg
Re: Renderer Programming
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 16.04.2003 10:43:12 J.U. Anderegg wrote:
> is shooting at a moving target, at least with FOP releases 0.20.x. The
> AbstractRenderer is formally stable,
I can tell you right now, that AbstractRenderer is not hammered into
stone in the redesign. It's going to change a bit as part of
Avalonization.
It's right that we don't have a shiny record about interface stability
but I intend to have a closer look in the future. The redesign, however,
is likely to change until we have a first release.
> but you are hardly able to tell how
> areas and area fields relate to XSL inputs. Is the geometry of areas
> documented anywhere: border and line stroke width, paddings included,
> half-inlcuded or excluded, which coordinates the renderer gets?
Internal coordinates are mostly millipoints. When I wrote the PostScript
renderer I used the PDF renderer as a reference to get things done.
What documentation we have on the redesign is in the following places:
- http://xml.apache.org/fop/design/index.html
- http://xml.apache.org/fop/design/alt.design/index.html
- http://nagoya.apache.org/wiki/apachewiki.cgi?FOPProjectPages
- in the code
> The AWT and my JPS renderer need
in the old FOP or in the redesign??? It's not clear from your post in
which direction you're shooting.
> - All pages accessible at any time, to view and print selected pages. Will a
> word still take about 1KB memory in the new design?
That's two different questions.
Pages are accessible through org.apache.fop.area.AreaTreeModel (and
descendants) in the redesign. In the maintenance branch the AWTRenderer
holds the pages in its own list I think.
Hopefully, a word will use less than 1KB memory in the redesign. If it
does you're welcome to help reduce memory usage.
> - PDF renderer classes: what for?
To generate high-quality PDF files, of course.
> - Font metrics: that's business of the formatter, the renderer might have to
> deal with physical fonts.
Correct. We're still in the process of rethinking the font support for
the redesign. Preliminary results at:
http://nagoya.apache.org/wiki/apachewiki.cgi?FOPFontSubsystemDesign
Help is welcome.
> Java Graphics2D (text, fonts) does lots of things much better, easier and
> most likely more efficently than present FOP.
It does? Do you happen to have figures?
AWT has proven to be problematic in the past, especially over different
JDK versions where behaviour changed.
> Regarding the new design there
> is a choice:
> - a home grown PDF program: forever limited function
> - a Java system, which might not fulfill the cute wishlist of XSL specs
> What are the new design decisions?
For the moment we're using our own PDF library and the PDF renderer. If
anybody provides an alternative, fine. Competition is good. Tickles the
best out of everybody. :-)
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org