about the question why the algorithms aren't simply copied
from Gecko (the Mozilla layout engine)
Now that the deadline has been extended, I'll attempt it again.
J.Pietschmann
. This also means that you have
to rewrite parts of your FO generator because of incompatible
changes in the spec (drafts) implemented by FOP.
J.Pietschmann
leave additional blank space on the right hand column before we
switch to single column layout.
This is due to a simple algorithm for balancing. Getting column
balancing even somewhat right is quite complicated.
J.Pietschmann
Jeremias Maerki wrote:
I see. I've added JAXP and Xerces to the classpath.
Isn't it somewhat strange that org.apache.xerces.parsers.SAXParser
is explicitely referenced? I'd think everyone uses JAXP meanwhile.
Do you access Xerces specific functionality?
J.Pietschmann
Puppala, Kumar (LNG-DAY) wrote:
Hello All,
Does anyone know what FO tags I need to use to generate a horizontal line
given the width, color and justification for this line?
Try fo:leader with some appropriate attributes.
J.Pietschmann
content clipped! Duh!
I vaguely remember a Mozilla/Firefox plugin which scales web
content to better fit printed pages too.
J.Pietschmann
in order to get it right. I personally
still think it should be integrated into break position
computation, with something like a whitespace state held in
the layout context.
J.Pietschmann
Bertrand Delacretaz wrote:
I have the great pleasure to announce that Jeremias Maerki has been
elected as an ASF member at the last member's meeting during ApacheCon.
Congratulations!
J.Pietschmann
the reader to pick
up the wrong continuation line (that's the reason for having
the hyphenation-ladder-count property). This tradeoff between
using hyphenation in order to avoid visual artefacts and
having lots of hyphenated words disrupting the flow has to be
balanced.
J.Pietschmann
also don't quite get the point about the
better SR'ability.
J.Pietschmann
,
the various html-* targets could be removed, couldn't they?
J.Pietschmann
constand inherited from Constants. Is this a bug or a feature new
in Java 1.4? Or is this just me?
BTW the buildfile could use some de-cruftification too (remove
the gensrc/.../properties stuff and a few now meaningless subtitutions)
J.Pietschmann
are into computer assisted
typesetting.
J.Pietschmann
Finn Bock wrote:
ValidateException is the right choice of exception when the FO file
doesn't follow the content model.
Nitpick: s/FO file/FO processor input document/
J.Pietschmann
:
- FOP release information
- Exact problem description (expected result vs. actual result)
- A reasonably small test case
J.Pietschmann
code.
Alternatively, you can
- parse into a DOM and use a DOMSource, if you don't mind
the potential memory overhead.
- derive a custom class from SAXSource which sets up a
properly custiomized parser instance, if you don't mind
the programming overhead.
J.Pietschmann
J.Pietschmann
Sam Ruby wrote:
[javac] ... warning: org.apache.commons.io.CopyUtils ... has been deprecated
[javac] import org.apache.commons.io.CopyUtils;
Jeremias, is there something we can do about this?
J.Pietschmann
are just that: processor *specific*
extensions.
There has been an EXSLFO initiative (search on sourceforge) in
order to get some extensions standardized, similar to EXSLT.
AFAIK nothing has been coming out of this, yet.
J.Pietschmann
Glen Mazza wrote:
There *might* be
more subtle issues
Just do the change locally, run the test suite (well...),
see if anything important breaks. If not, check in.
J.Pietschmann
Simon Pepping wrote:
I propose that we make Luca Furini a member of the FOP team.
+1 from me.
Regards
J.Pietschmann
no namespace, and call validation for elements
and attributes from other namespaces in roder to give them a
chance to validate themselves.
J.Pietschmann
breaks.
J.Pietschmann
of this?
J.Pietschmann
.
J.Pietschmann
Glen Mazza wrote:
Just updated the two libraries source code on
maintenance and HEAD. (Only took 45 minutes...not
bad!)
Great!
J.Pietschmann
?
J.Pietschmann
J.Pietschmann wrote:
I wonder why HEAD isn't affected?
Darn, HEAD got it too :-/
J.Pietschmann
, users hardly care. I wish everybody would expend the
energy on more pressing issues.
J.Pietschmann
Victor Mote wrote:
I mention it only to point out the *real* issue in case any
real FOP stakeholders are interested.
Well, the real stakeholders (aka users) are probably more
interested in working footnotes, or multi-column layout.
J.Pietschmann
in the above case wont be rendered, and it's quite
difficult to reliably check for this condition. If there can only
be a single fox:bookmark, error checking is much easier. Some would
also claim it enforces better writing style.
J.Pietschmann
. The
XSLTInputHandler predates JAXP by quite a bunch of months.
J.Pietschmann
Jeremias Maerki wrote:
[ ] I vote for Peter B. West as PMC chair.
[X] I vote for Jeremias Maerki as PMC chair.
J.Pietschmann
, if the problem still persists.
It might be prudent to check whether the source doesn't already contain
the wrong URL.
J.Pietschmann
Peter B. West wrote:
I will be offline for the next week. I'm marrying Jenni tomorrow, and
honeymooning in the frozen south of the South Island of New Zealand for
a week.
Congrat's from me too have a nice week.
J.Pietschmann
produce.
Check *all* points mentioned in
http://xml.apache.org/fop/running.html#memory
Tables in particular cause a linearly increasing memory consumption due
to a sort of a memory leak. If you are adventurous, there is an
unreleased fix for this in the repository.
J.Pietschmann
.
J.Pietschmann
this.
J.Pietschmann
agent should qualify.
Static objects are bad because of the usual MT issues (yeah,
even for logging).
J.Pietschmann
caches
- Object pools (although they are said to decrease performance
for modern JREs)
J.Pietschmann
for images
etc.
J.Pietschmann
the largest amount of memory.
J.Pietschmann
possiblities from
the child LMs.
J.Pietschmann
this argument. Handling space-before is also
fo:block specific. Where should this logic be put, then? Note that
whitespace handling includes removing spaces around line breaks which
are introduced during the layout process.
J.Pietschmann
, but perhaps it is.
Regards
J.Pietschmann
hyphenations
return previous break possiblity
*end for*
*end for*
Regards
J.Pietschmann
Hi all,
I'm offline for the next two weeks.
Have fun!
J.Pietschmann
.
I came across a subclass*** Class BaselineShiftMaker* in the API doc but
its not distributed with the snapshot of the source !?
It's code generated during the build.
J.Pietschmann
contributed files should be put under APL which
means all issues have to be resolved before the file is committed to
CVS.
J.Pietschmann
filter anyway (which means you have to provide a
nop filter in order to have a look at the uncompressed
PDF code).
2. The fop.xconf, userconfig and command line options
are not merged, although they should.
J.Pietschmann
in the past, this
seems to be the first time a worm managed to get to the
subscription barrier on its own.
J.Pietschmann
.
J.Pietschmann
stumbling over them just stopped using FOP.
It's certainly better to check.
J.Pietschmann
Glen Mazza wrote:
[...]
+1
J.Pietschmann
ahead and create out own
Wiki already?
The other issue: The hyphenation files with problematic
licenses are apparently still in the HEAD CVS ready for
checkout. I can't remember any status change here. What
should we doe with them?
J.Pietschmann
is as it is.
J.Pietschmann
, Jeremias asked last
year, without any result so far, I think.
J.Pietschmann
. The reason for this is
that it's only the renderer which knows when page number
references are resolved.
How will this fit in now?
BTW I don't think it's good style do ignore a veto and
commit a change even before the discussion is resolved.
J.Pietschmann
methods instead of switch according to a
class marker.
and remove the bounce-back between
Renderers and Area objects, further simplifying the coding.
But this is what keeps the renderers pluggable. If these
methods are removed, every renderer must follow the same
design.
J.Pietschmann
to implement that.
Me too :-)
Should we delay my proposed patch until somebody has come up with an
implementation that pass the LayoutContext to all Length.getValue(lc)
calls?
I don't see much value in delaying your patch, but let's keep
an eye (or bugzilla entry) on this issue.
J.Pietschmann
the FO tree holds properties (parsed property expressions), while
the layout context and the area tree hold the refined traits.
J.Pietschmann
where a new Layout context is
created for getting BP from the child LM.
J.Pietschmann
driven computer
with 4k RAM and 12k ROM. That's enough to run a program
which nicely prints formatted and justified text (25 lines
a 80 characters). We went a lng way since then.
J.Pietschmann
, and the
inherited property can grab the absolute value immediately.
J.Pietschmann
for reusing objects and for trying to
replace objects with a bunch of primitive values.
(BTW a nice try selling yet-to-be-written optimizations
regarding inlining...)
J.Pietschmann
. Like
textIndent=propertyManager.get(TEXT_INDENT).resolve(layoutContext);
I still think it is easier to use either the FOs or the LMs .
Maybe.
J.Pietschmann
Finn Bock wrote:
Somehow, in our current design, the information must be stored in an
object that exists:
IIRC that's what the layout context was meant for.
J.Pietschmann
Chris Bowditch wrote:
Jeremias to remain as one of our PMC representatives:
+1
+1 for Jeremias
Me too
+1
J.Pietschmann
for such
contingencies?
The current code relies on extensions of JRE core classes. I don't
think this could be easily retrofittet to a pre 1.4 JRE, unless
you *like* fiddling with the bootclasspath.
J.Pietschmann
,
mainly upgrading essential software services, the whole OS, or
even hardware upgrades.
From what I heard, development efforts are meanwhile firmly based
on 1.4, everything based on 1.3 is strictly maintenance, with
a gradual migration to 1.4.
J.Pietschmann
of the error.
On 07.02.2004 23:56:40 J.Pietschmann wrote:
I get a nice Junit failure:
java.lang.LinkageError:
The JUnit FAQ explains this nicely.
J.Pietschmann
on 1.3 deployed, and
upgrading a working service is usually frowned upon, even if a
convenient path is available.
Given that FOP 1.0 wont be released until at least late this year,
if not later, we could tell our 1.3 users to use 0.20.5 and
declare 1.4 the minimum for 1.0.
J.Pietschmann
a handcrafted XML reader as 0.20.5 does, or
using JNDI like J2EE.
No shortage of ideas at all :-)
J.Pietschmann
)
at org.apache.fop.BasicDriverTestCase.
testFO2PDFWithDOM(BasicDriverTestCase.java:149)
This seems to have something to do mixing Jars form the JDK and
fop/lib. Does anybody have an idea how this can be avoided?
J.Pietschmann
like to get rid of the servlet.jar in our CVS.
2. If we standardize on JDK 1.4 as base (as it currently
is), we could drop the Xerces, Xalan and xml-api jars as
well. Our Jars seem to be somewhat outdated anyway.
J.Pietschmann
after the last detail-block for
which it contains the link...
I don't understand the problem. Could you trim it down to two detail blocks,
and post the FO (assuming the trimmed down FO still has the problem)?
J.Pietschmann
starts and each time a block ends. The start of a new block
forces a new line, so you can finish the current line,
including whitespace processing.
J.Pietschmann
Glen Mazza wrote:
Well, instanceof is slower I believe, but better
self-commenting.
Instanceof is exactly as fast as a simple function call
after warm-up.
J.Pietschmann
renderer's character event call. You still have to
delay some output because space before/after a line break must be
stripped for many settings.
What are the difficulties for nested blocks?
J.Pietschmann
faster (~1%) than a foo(){return true;}. It may have
something to do with the test setup. I wouldn't rule out
I tested in a class without inheritance :-)
J.Pietschmann
of spec
makes it unnecessary hard to follow.
J.Pietschmann
normalization and line breaking (for SVG flow text)
- command line wrapper
- common area rendering
- embedded images, of course
- API concerns, as discussed: hooks for custom resolvers for fonts,
images, URLs in general
J.Pietschmann
Tibor Vyletel wrote:
I would like to ask, what's the reason why PageViewport class is not
descended from Area class.
Mainly because it's not an area. It makes a difference for example
for rendering into AWT windows and such.
J.Pietschmann
parsed as expression, while
an optimized parser can take advantage of the lack of any string
operations and look for quoted strings and function calls only,
returning the trimmed XML attribute value otherwise.
Finally, bless the Mozilla and MySpell folks for the spell
checker... :-)
J.Pietschmann
(7.20.1) is yet another challenge to parse.
J.Pietschmann
Siarhei Baidun wrote:
If you have more exact suggestion, share please.
Probably .../org/apache/fop/renderer/pdf/fonts/MultiByteFont.java,
One of them is we are planning
to make porting on new FOP (from main branch)
Don't hold your breath here.
J.Pietschmann
for bootstrap)
which produces a proper parse tree.
3. Add methods to the objects for resolving relative numeric values
(percentages, em) and for evaluation.
4. Perhaps add constant folding to the parser.
J.Pietschmann
subdirectory or in LineArea.java.
You can try a CVS diff for a start.
Is there a specific reason why you can't simply upgrade? especially
the 0.20.4rc had a few nasty deficiencies.
J.Pietschmann
[EMAIL PROTECTED] wrote:
removed former contributor
section in favor of going back to giving credit within source files.
Uh, oh. That's not supposed to be a change anybody can make
on a whim.
J.Pietschmann
of the two superfluous? Do they complement
each other? Shouldn't the latter be rewritten as :
this.BackgroundColor = bProps.backColor
I'd think so.
J.Pietschmann
this.
J.Pietschmann
to learn what an URI is. This seems to be much harder
than expected, especially for file:-URLs.
- People will still insist to keep xml=foo.xml. This is still an
URL (actually: a relative URL reference, which has to be resolved).
We have to think hard what the base URL is in this case.
J.Pietschmann
names to their associated classes or
code numbers.
J.Pietschmann
/
/xsl:apply-templates
Substitute in the xsl:sort's select whatever is the sort key.
J.Pietschmann
for the various hashmaps currently used.
J.Pietschmann
Chris Bowditch wrote:
I lean somewhat to the first strategy, because memory is usually more
of a problem then bare performance.
This appears to be a contradiction, did you mean the last strategy?
Well, I meant the second (free memory as early as possible).
J.Pietschmann
choice, I wont object.
J.Pietschmann
) {
String word = tok.nextToken();
renderText(x,y,word);
x+=width(word);
x+=adjustedSpaceWidth;
}
There is a tradeoff between avoiding recomputing the word width and
carrying it around for probably some significant time.
J.Pietschmann
the problem
that the leaders have to be aligned *after* space justification, which is
still broken in 0.20.5.
I'm going to change this to set
TSAdjust to dAdjust.
Is this really a good idea?
J.Pietschmann
reasons. It's definitely not a fault with the FOP
code.
J.Pietschmann
1 - 100 of 597 matches
Mail list logo
