On 13.08.2002 23:15:39 J.Pietschmann wrote:
Jeremias Maerki [EMAIL PROTECTED] wrote:
The FO objects are primarily just data holder, so it doesn't make
sense to make them too heavy-weight. They need to be as light-weighted
as possible to save memory. Most of the logic is transferred to
Hi Victor
Any news on OpenType support? I haven't done a lot of thinking about my
upcoming proposal on centralized font support. Well, I have to admit
that it's a low priority thing. I'll start it when I'm going to dive
deeper into the Avalon things. But that shouldn't stop you from working
on
This email is autogenerated from the output from:
http://jakarta.apache.org/builds/gump/2002-08-14/xml-fop.html
Buildfile: build.xml
Caught exception (org.apache.tools.ant.BuildException)
Looks like the Batik guys have changed the TextPainter interface without
thinking about dependencies on other projects. Keiron, shall we make the
changes to conform to their new interface or should they reconsider this
change?
This is the link to TextPainter in Batik's CVS:
J.Pietschmann wrote:
appropriate cast. Unfortunately, in the maintenance branch
the children vector is protected and directly accessed in a
lot of places, putting the test+cast code and the handling
of the one-child-only special case everywhere seemed to be
too much work. Writing a custom
J.Pietschmann wrote:
- If the FO objects are primarily data holders, why
have them at all, instead of using a standard DOM?
I believe standard DOM implementations are obviously too synchronized to
provide thread-safe access, while fo tree is built sequentially and is
read-only after its
keiron 2002/08/14 06:45:45
Modified:lib batik.jar
src/org/apache/fop/svg PDFTextPainter.java SVGUserAgent.java
.status.xml
Log:
Updated batik with change to TextPainter interface and UserAgent.
Improved PDFTextPainter to handle more
keiron 2002/08/14 07:25:18
Modified:src/org/apache/fop/fo FOTreeBuilder.java
Log:
made messages more sensible
Revision ChangesPath
1.40 +3 -3 xml-fop/src/org/apache/fop/fo/FOTreeBuilder.java
Index: FOTreeBuilder.java
Jeremias:
Any news on OpenType support? ... it's a low priority thing.
I haven't done much with it yet. I thought it important for me to learn my
way around FOP before trying to start any coding. After starting that, I
decided that the javadocs could really use some work, especially at the
Keiron Liddle wrote:
- Add static areas to page
The static areas will need to be handled in a similar way to the flow
except the bpd is unlimited and it will need to reset and repeat for
each page.
I looked at it. Is static content supposed to be handled
by a FlowLayoutManager too? It
Hello all,
I just took a more extended look at CVS HEAD. There are
some style issues which caught my eye.
1. I'd appreciate if indentation uses spaces instead of
tabs. And because I can avoid using tabs, I expect
everyone else avoiding tabs too.
2. I'd really, really appreciate if
pietsch,
Style judgements are a very personal matter. Personal tastes follow.
J.Pietschmann wrote:
1. I'd appreciate if indentation uses spaces instead of
tabs. And because I can avoid using tabs, I expect
everyone else avoiding tabs too.
This is pretty much a necessity because of
Joerg, Keiron, et al,
This is why I have harped on the theme of lookahead. The layout design
simply must accommodate it, and must be able to preserve as much
information as possible from the initial layout attempts to minimise the
work of subsequent attempts. I have, as I have said before,
J.Pietschmann wrote:
Peter B. West wrote:
More less than more, I should think. Parsing is inherently generic.
E.g., I assume that you would use the same tokenizer and first-level
parser.
At the tokenizer level, sure. However, the spec provides for
a wildly varying spectrum of
14 matches
Mail list logo
