.
Acutually I doubt FOP 0.20.5 will run completely in an 1.2 environment.
The binary is compiled with 1.4.1, and I vaguely remember compiling
problems already for 0.20.4 on 1.2.
J.PIetschmann
probably important to many users. THere is a slo a minor fix
concerning leader expansion there.
J.Pietschmann
support in the
current development version of FOP but I'm having a hard time figuring
out exactly what bits are involved.
If you like contorted XSLT and abysmal performance, just use the
metric XML files directly. The content should be fairly obvious.
J.Pietschmann
ld be necessary. But I think if there are problems
which are not in 0.20.5, and it's not absolutely obvious how to fix them,
we just tell people to continue to use 0.20.5.
J.Pietschmann
y be other reasons. It's definitely not a fault with the FOP
code.
J.Pietschmann
m going to change this to set
TSAdjust to dAdjust.
Is this really a good idea?
J.Pietschmann
okens ) {
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
aping!
J.Pietschmann
user choice, I wont object.
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
without drawbacks:
- People have 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
g
to FO and property names to their associated classes or
code numbers.
J.Pietschmann
Glen Mazza wrote:
)
...
I am not an XSLT guru--offhand, does anyone know of a
simple way to get the interfaces to appear
alphabetically?
It ought to be
Substitute in the xsl:sort's select whatever is the sort key.
J.Pietschmann
ial size
values for the various hashmaps currently used.
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
to do this.
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
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
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
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
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
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
e within a few days.
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
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
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
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
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
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
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
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
. 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
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
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
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
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
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
Chris Bowditch wrote:
Jeremias to remain as one of our PMC representatives:
+1
+1 for Jeremias
Me too
+1
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
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
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
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
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
where a new Layout context is
created for getting BP from the child LM.
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
y
the FO tree holds properties (parsed property expressions), while
the layout context and the area tree hold the refined traits.
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
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
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
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
maintenance code is as it is.
J.Pietschmann
least ask. Well, Jeremias asked last
year, without any result so far, I think.
J.Pietschmann
Glen Mazza wrote:
[...]
+1
J.Pietschmann
problems though.
J.Pietschmann
used functionality, and
people stumbling over them just stopped using FOP.
It's certainly better to check.
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
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
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
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
Glen Mazza wrote:
Thoughts? Votes?
-0 (not a veto)
J.Pietschmann
Hi all,
I'm offline for the next two weeks.
Have fun!
J.Pietschmann
ot sure whether this is
sufficient, but perhaps it is.
Regards
J.Pietschmann
use both LF and CRLF line endings (but always
create CRLF line endings).
J.Pietschmann
hyphenations
return previous break possiblity
*end for*
*end for*
Regards
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
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
ock up the largest amount of memory.
J.Pietschmann
.
J.Pietschmann
user agent should qualify.
Static objects are bad because of the usual MT issues (yeah,
even for logging).
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
for images
etc.
J.Pietschmann
.
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
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
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
Jeremias Maerki wrote:
[ ] I vote for Peter B. West as PMC chair.
[X] I vote for Jeremias Maerki as PMC chair.
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
should
be small and rare.
J.Pietschmann
AXP is more or less ubiquitous. The
XSLTInputHandler predates JAXP by quite a bunch of months.
J.Pietschmann
would
also claim it enforces better writing style.
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
real
work, users hardly care. I wish everybody would expend the
energy on more pressing issues.
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
J.Pietschmann wrote:
I wonder why HEAD isn't affected?
Darn, HEAD got it too :-/
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
orsed.dirs.
J.Pietschmann
care of this?
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
s like Karen's extension elements shown before or
after page breaks.
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
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
Simon Pepping wrote:
I propose that we make Luca Furini a member of the FOP team.
+1 from me.
Regards
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
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
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
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
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
se provide:
- FOP release information
- Exact problem description (expected result vs. actual result)
- A reasonably small test case
J.Pietschmann
1 - 100 of 700 matches
Mail list logo
