e, a PATRICIA tree or whatever)
- Talk 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
.20.5. 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
n the right hand column. Doing
this would 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
page numbers worked then.
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
Ex printouts without any
content clipped!" Duh!
I vaguely remember a Mozilla/Firefox plugin which scales web
content to better fit printed pages too.
J.Pietschmann
er content 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
cause 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
and Eclipse. I also don't quite get the point about the
better S&R'ability.
J.Pietschmann
e is generated by Forrest,
the various html-* targets could be removed, couldn't they?
J.Pietschmann
SPACE
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
ad" if you are into computer assisted
typesetting.
J.Pietschmann
se provide:
- FOP release information
- Exact problem description (expected result vs. actual result)
- A reasonably small test case
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
rok sample 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
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
sions 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
Simon Pepping wrote:
I propose that we make Luca Furini a member of the FOP team.
+1 from me.
Regards
J.Pietschmann
n the block. Trailing whitespace util the
closing tag is normalized away (or should be, FOP shows bugs here).
Why do you think it is otherwise?
J.Pietschmann
p-in extensions have
to be mutually exclusive.
If the current node is an fo:list-item and the
incoming node represents an fo:layout-master-set,
raise the exception immediately before you even get to
instantiate the fo:layout-master-set.
This does not mean you have to summarily reject a
finnbock:change-bar on the same grounds.
J.Pietschmann
s like Karen's extension elements shown before or
after page breaks.
J.Pietschmann
om no namespace, and call validation for elements
and attributes from other namespaces in roder to give them a
chance to validate themselves.
J.Pietschmann
care of this?
J.Pietschmann
orsed.dirs.
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 wrote:
I wonder why HEAD isn't affected?
Darn, HEAD got it too :-/
J.Pietschmann
ze(){
GUMP was designed exactly for the purpose of detecting these
problems. Which doens't give much of a guidance how to handle
this specific instance. We could just ignore it, and/or remove
fop-maintenance from the nightly GUMP.
I wonder why HEAD isn't affected?
J.Pietschmann
real
work, 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
would
also claim it enforces better writing style.
J.Pietschmann
AXP is more or less ubiquitous. The
XSLTInputHandler predates JAXP by quite a bunch of months.
J.Pietschmann
should
be small and rare.
J.Pietschmann
should be a clear distinction between the API
and application wrappers. I suggested an API package
containing a FOProcessor, and keep the apps package
clean. Perhaps create subpackages in apps for CLI,
servlet, AWT or whatever sample/useful applications.
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
d, if necessary
- Submit bug report, 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
the reports we 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
.
J.Pietschmann
for images
etc.
J.Pietschmann
ngs and fallback options
- Global font and perhaps image caches
- Object pools (although they are said to decrease performance
for modern JREs)
J.Pietschmann
user agent should qualify.
Static objects are bad because of the usual MT issues (yeah,
even for logging).
J.Pietschmann
ock up the largest amount of memory.
J.Pietschmann
ey think
a line is full, rather similar to the maintenance branch code. The break
possibility bubles up to the nearest block layout manager, which stores
it, updates the BPD and goes ongetting further break possiblities from
the child LMs.
J.Pietschmann
anagers, because it is fo:block
specific
I don't quite understand 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
hyphenations
return previous break possiblity
*end for*
*end for*
Regards
J.Pietschmann
use both LF and CRLF line endings (but always
create CRLF line endings).
J.Pietschmann
ot sure whether this is
sufficient, but perhaps it is.
Regards
J.Pietschmann
Hi all,
I'm offline for the next two weeks.
Have fun!
J.Pietschmann
Glen Mazza wrote:
Thoughts? Votes?
-0 (not a veto)
J.Pietschmann
lcome.
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
whole issue.
Of course, newly contributed files should be put under APL which
means all issues have to be resolved before the file is committed to
CVS.
J.Pietschmann
lists by clueless people in the past, this
seems to be the first time a worm managed to get to the
subscription barrier on its own.
J.Pietschmann
e uses a
flate 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
used functionality, and
people stumbling over them just stopped using FOP.
It's certainly better to check.
J.Pietschmann
problems though.
J.Pietschmann
Glen Mazza wrote:
[...]
+1
J.Pietschmann
least ask. Well, Jeremias asked last
year, without any result so far, I think.
J.Pietschmann
maintenance code is as it is.
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
r() method. 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
sed 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
nciples: use
virtual 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
y
the FO tree holds properties (parsed property expressions), while
the layout context and the area tree hold the refined traits.
J.Pietschmann
years ago, I had to work on a 8008 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
where a new Layout context is
created for getting BP from the child LM.
J.Pietschmann
ments 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
used when we evaluate the
10% even when we call:
propertyList.get(PR_BORDER_START_WIDTH).getValue(lc)
with the layout context for 'b'.
Well, I used to believe the 10% has been evaluated already, and the
inherited property can grab the absolute value immediately.
J.Pietschmann
s for
percentages. 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
n 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
Chris Bowditch wrote:
Jeremias to remain as one of our PMC representatives:
+1
+1 for Jeremias
Me too
+1
J.Pietschmann
some sort of SAX event extension (for
PSVI support). Using it seems somewhat risky though,
the APIs have some tendency to change suddenly.
J.Pietschmann
wording 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
fects,
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
ng XML, using a handcrafted XML reader as 0.20.5 does, or
using JNDI like J2EE.
No shortage of ideas at all :-)
J.Pietschmann
ave servers based 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
. I'd 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
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
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
ghtly
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
structure 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
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
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
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
lly meant to be
a "compound" property, like space-before. I.e. it is possible
to write
I see why they thought this is necessary, but this kind of spec
makes it unnecessary hard to follow.
J.Pietschmann
e within a few days.
J.Pietschmann
operties may have the value "inherit",
which is both defined as a keyword in the grammar and quite often
explicitely enumerated in the property description. And the "clip"
property (7.20.1) is yet another challenge to parse.
J.Pietschmann
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
ANTLR, at least 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
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
n the font 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
to do this.
J.Pietschmann
two superfluous? Do they complement
each other? Shouldn't the latter be rewritten as :
this.BackgroundColor = bProps.backColor
I'd think so.
J.Pietschmann
1 - 100 of 700 matches
Mail list logo
