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.Pietschmann" <j3...@yahoo.de> on 2003/04/15 00:52:25 UTC
Re: Plan for HEAD
Keiron Liddle wrote:
> Mostly we need to get the renderers back and fix/improve some layout things like
> forced page break, table cell spanning, couple of problems calculating current bpd.
I thought I start pushing head again, and the first problem jumping
into my face was that text-align="justify" was broken. Unfortunately,
I can't figure out how text alignment is supposed to work. Furthermore,
I think alignment should be done after page-numbers-citations are
resolved which again is something I can't figure out how it fits in.
Other problems: text-align-end is not used at all, illegal and/or
unimplemented property values give no diagnostic and cause seemingly
random behaviour, and background fill areas are not computed correctly.
This is just from 15 minutes of creating and running the most primitive
tests.
Several attempts ended in getting me almost catatonic because of
the various design oddities, inconsistently used naming conventions
and utterly illogical identifier and package choices. I don't think
I'll ever get a line of code written in the layout core without
someone doing a major clean-up before.
So what should I do now? Do some peripheral stuff like fiddling
a bit with the API/Avalonization? Fix one or another bug in the
maintenance code, knowing that it will probably all thrown away?
Just twiddling thumbs, waiting for the occasions where Keiron or
even Karen resurface and give HEAD a push?
At a loss
J.Pietschmann
---------------------------------------------------------------------
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
Re: Plan for HEAD
Posted by Jeremias Maerki <de...@greenmail.ch>.
Sorry, didn't fit into this week. And I'll be away from today on until
2003-05-01. Will report right after I'm back.
On 25.04.2003 01:27:21 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> >> I could use a second opinion.
> > Will do.
>
> ETA?
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Plan for HEAD
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
>> I could use a second opinion.
> Will do.
ETA?
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Plan for HEAD
Posted by Jeremias Maerki <de...@greenmail.ch>.
Will do.
On 15.04.2003 23:14:01 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > Why don't you start by fixing these inconsistencies? That may also help
> > you to get a better feel for the new layout engine.
>
> I tried.
> Just take an hour and have a look into the layout core by yourself,
> with a special emphasis on the text justification problem, and make
> an estimate how long it would take you to understand what's going on,
> make a list of changes you'd attempt and how much effort this would
> take. I could use a second opinion.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Plan for HEAD
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> Why don't you start by fixing these inconsistencies? That may also help
> you to get a better feel for the new layout engine.
I tried.
Just take an hour and have a look into the layout core by yourself,
with a special emphasis on the text justification problem, and make
an estimate how long it would take you to understand what's going on,
make a list of changes you'd attempt and how much effort this would
take. I could use a second opinion.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Renderer Programming
Posted by "J.U. Anderegg" <ha...@bluewin.ch>.
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: Plan for HEAD
Posted by Jeremias Maerki <de...@greenmail.ch>.
Why don't you start by fixing these inconsistencies? That may also help
you to get a better feel for the new layout engine.
The API and Avalonization are two different topic IMO. I have plans for
the Avalonization part but I'm still in the final stages of finishing up
a 1.0beta of my barcode library at Krysalis. After that I'll be back at
FOP. I've also been trying to get some changes into Jakarta Commons IO
but that proves to be non-trivial. I'll push again this week I think.
Another item for me is our transcoder package. I want to have EPS output
support. And a beta release of the transcoder package is also on the
list.
On 15.04.2003 00:52:25 J.Pietschmann wrote:
> Keiron Liddle wrote:
> > Mostly we need to get the renderers back and fix/improve some layout things like
> > forced page break, table cell spanning, couple of problems calculating current bpd.
>
> I thought I start pushing head again, and the first problem jumping
> into my face was that text-align="justify" was broken. Unfortunately,
> I can't figure out how text alignment is supposed to work. Furthermore,
> I think alignment should be done after page-numbers-citations are
> resolved which again is something I can't figure out how it fits in.
> Other problems: text-align-end is not used at all, illegal and/or
> unimplemented property values give no diagnostic and cause seemingly
> random behaviour, and background fill areas are not computed correctly.
> This is just from 15 minutes of creating and running the most primitive
> tests.
>
> Several attempts ended in getting me almost catatonic because of
> the various design oddities, inconsistently used naming conventions
> and utterly illogical identifier and package choices. I don't think
> I'll ever get a line of code written in the layout core without
> someone doing a major clean-up before.
>
> So what should I do now? Do some peripheral stuff like fiddling
> a bit with the API/Avalonization? Fix one or another bug in the
> maintenance code, knowing that it will probably all thrown away?
> Just twiddling thumbs, waiting for the occasions where Keiron or
> even Karen resurface and give HEAD a push?
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org