Hi Glenn,
sure, I agree if work is going on incorporating new features of
xmlgraphics-commons, then you wouldn't want to update its version every week.
However, the best practices I learned are to develop against official APIs as
soon as possible.
I was under the impression that the work concerning xmlgraphics-commons is
already months old and that the dependency on the trunk version has perhaps
been overlooked.
Kind regards,
Ulrich
Glenn Adams wrote:
Ulrich,
It is not uncommon for works under development (as is the case in the
trunk) to depend on the latest version of a dependent JAR (e.g.,
xmlgraphics-commons). That's just the nature of the dev process. The same
applies for the APIs and Docs.
What you are asking for is appropriate for the next release (whatever
number turns out to be applied), but is an ongoing process in the trunk.
That's part of the risk/reward aspect of using an unreleased version. You
have to spend more effort to use it, but you gain from its new features,
fixes, etc.
Regards,
Glenn
On Fri, May 31, 2013 at 1:36 AM, Ulrich Mayring u...@denic.de wrote:
Oh, and another thing: the new code depends on an unspecified trunk
version of xmlgraphics-common. That makes it very hard to track bugs, as I
might have another version than someone else. If no new release of
xmlgraphics-common is available I would strongly suggest to depend on a
specific nightly build, so that everyone downloading fop-trunk is on the
same page with respect to external dependencies.
Kind regards,
Ulrich
Ulrich Mayring wrote:
Hello Luis,
the problem with this approach is that not all setter-methods that were
available in FopFactory are now available in the builder. Also, please
note
that the docs haven't been updated, they still suggest to do it the old
way.
For example, if you look at
http://xmlgraphics.apache.org/**fop/trunk/embedding.html#**
config-internalhttp://xmlgraphics.apache.org/fop/trunk/embedding.html#config-internalyou'll
find that the first two methods listed there are not available in the
builder.
Kind regards,
Ulrich
Luis Bernardo wrote:
See this thread:
http://mail-archives.apache.**org/mod_mbox/xmlgraphics-fop-**
users/201302.mbox/%3c512D5B3C.**8060...@gmail.com%3ehttp://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201302.mbox/%3c512d5b3c.8060...@gmail.com%3e
On Wednesday, May 29, 2013, Ulrich Mayring wrote:
Ooops, the newest Nightly Build has changed the Interface of FopFactory
and FontManager. All the setter-methods in those classes are gone. How
can
I programmatically configure FOP now? The docs under
http://xmlgraphics.apache.org/fop/trunk/embedding.html#
config-internalhttp://xmlgraphics.apache.org/**fop/trunk/embedding.html#**config-internal
http://**xmlgraphics.apache.org/fop/**trunk/embedding.html#config-**
internalhttp://xmlgraphics.apache.org/fop/trunk/embedding.html#config-internal
still
suggest the old way.
cheers,
Ulrich
Ulrich Mayring wrote:
Hi Glenn,
thanks for the pointer, your suspicion was correct. With the latest
nightly
build the page is rendered like it was in FOP 0.95, which I believe is
the
correct way.
Thanks a lot,
Ulrich
Glenn Adams wrote:
I would suggest you check the current trunk (you can use a nightly
build
if
you don't want to build yourself). There were some fixes in this are
since
1.1.
On Wed, May 29, 2013 at 6:56 AM, Ulrich Mayring u...@denic.de
wrote:
Hi all,
please find attached an FO file and two PDFs, which were rendered
from
it.
One was rendered by FOP 0.95, while the other was rendered by FOP
1.1.
If you compare the PDFs, you'll see that the header Price (EUR) as
well
as the value 8,888,888.88 jut out to the right in the FOP 1.1
rendering,
while they look fine in the FOP 0.95 output.
The structure of the fo:table is such that the rightmost column is
too
small to fit either of these two items, so they have to overflow the
table
cell in some way (cut off is not an option here). In FOP 0.95 the
items
flow out to the left, practically into the previous table cell, but
there
is enough room to accommodate them. Whereas FOP 1.1 flows the items
out
to
the right of the table cell, which in this case looks ugly.
My questions are: can I get the old rendering behavior back? Perhaps
by
changing something in the FO? And who is actually doing the right
thing,
FOP 0.95 or FOP 1.1?
Note: in FOP 1.1 these were rendered with the Complex Scripts
feature
off, so as to minimise variation between FOP 0.95 and 1.1.
Many thanks in advance for any pointers,
Ulrich
--**--**
-
To unsubscribe, e-mail: fop-users-unsubscribe@**
xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.**
apache.org fop-users-h...@xmlgraphics.apache.org
--**
--**-
To unsubscribe, e-mail:
