From: Glen Mazza [EMAIL PROTECTED]
That *could* be a solution--I added toString() methods
in the LayoutContext to help track the state of values
in that class.
Glen
Thanks to Glen and Joerg for replying to this. Setting FIRST/LAST flags on
LayoutContext in the layoutMgr.addArea code isnt enough
I'm still analyzing the problem at this time.
--- Chris Bowditch [EMAIL PROTECTED] wrote:
From: Glen Mazza [EMAIL PROTECTED]
That *could* be a solution--I added toString()
methods
in the LayoutContext to help track the state of
values
in that class.
Glen
Thanks to Glen and Joerg
Chris Bowditch wrote:
I'm not sure where Layout Contexts should be instantiated. Any thoughts?
The are created in the getNextBreak stuff.
I'm sure conditional spaces as well as keeps and proper line breaking
will need enhancements, in particular an object holding the cond-space
state across the
Question, Joerg, we implement fo:block as multiple
Area.Blocks in those cases where an fo:block would
consume more than one page (or, more precisely, its
assigned region on the page). One Area.Block for each
page the fo:block consumes.
I am assuming this is just an implementation
convenience for
Glen Mazza wrote:
I am assuming this is just an implementation
convenience for us--just to confirm, the spec does
allow for an fo:block to consume more than one page,
correct? I wasn't able to find otherwise.
Well, the spec always has this phrase one or more areas.
It doesn't really explicitely
I've always assumed that the one or more areas are a logical consequence
of the fact that generating FOs may overflow a page. The area tree
describes laid-out areas to be rendered on some medium, and every area
which describes a mark on a page must have a region in its ancestry, we
are
Thank you both for the clarifications.
--- Peter B. West [EMAIL PROTECTED] wrote:
The area tree
describes laid-out areas to be rendered on some
medium, and every area
which describes a mark on a page must have a region
in its ancestry, we
are obliged to consider individual FOs
Glen Mazza wrote:
Thank you both for the clarifications.
--- Peter B. West [EMAIL PROTECTED] wrote:
The area tree
describes laid-out areas to be rendered on some
medium, and
as
every area
which describes a mark on a page must have a region
in its ancestry, we
are obliged to consider
Hi, everyone.
I recently come across to that the SVG output and PDF
output are slightly off each other.
Take a look at the examples\basic\simple.fo, the
difference starts at the 4th line, in SVG, it ends
with
word with while in PDF, it ends with both. This
difference is small for font
Hi George,
The SVG output uses the AWT font metrics of the current system, which is the
same font metrics that Batik uses to do the text rendering.
Whereas the PDF output uses the PDF font metrics which are standardized
across any system.
These metrics are often different which will explain
gmazza 2003/11/10 20:40:12
Modified:src/java/org/apache/fop/layoutmgr BlockLayoutManager.java
BlockStackingLayoutManager.java
Log:
fo:block space-before property now activated only on the first Area.Block object used
in rendering the fo:block. (Previous
This sounds bad, shouldn't FOP take the charge of font
metric measurement before rendering to different
format?
Does this mean that for different fonts, SVG output
will alway have the same number of character in each
line?
George
--- Keiron Liddle [EMAIL PROTECTED] wrote:
Hi George,
The
--- Chris Bowditch [EMAIL PROTECTED] wrote:
One possible workaround is for Layout Managers to
record this state
themselves. Not sure if thats acceptable though as
it means greater memory
consumption.
Chris
Yes, that it what I did. Thanks for your
suggestion--space-before seems to
This sounds bad, shouldn't FOP take the charge of font
metric measurement before rendering to different
format?
It does, the font metrics for SVG are the AWT metrics taken from java which are
from the current platform.
Does this mean that for different fonts, SVG output
will alway have the
14 matches
Mail list logo
