Some kind of reply to this (old) message :
http://markmail.org/message/iyyco7ffxs6qj2i7
I confirm this problem also in 0.95beta
The AWT display order is not reversed here :
pages 1,2,3...N are displayed in that order :
N, 1, 2, 3 ... N-1
This bug only appears if my document has a
that refers to
Hello,
I have a strange behaviour for table rendering, which I can't explain.
See example below.
Basically, if number-columns-spanned > 1, the border-bottom property
is applied only to first (original) cell. The next cells only have half the
border thickness (example line 2).
This is not the case
We generate FOP documents from a *nix workhorse, a rather plain (bare)
server that has very minimal graphics & font equipment.
The current setup works well for current fonts (say, Verdana) and
custom-made technical fonts.
Now, I would like to use some glyphs from the Symbol font but this
raises
Thanks for all your answers.
Unfortunately, I won't be able to use the GC to free the open handle as:
- we will have loads of concurrent fop transformation running in services
deployed on a same app server instance,
- the open handle makes undeploying a service tricky and manually calling
the GC
I think there's an issue in how FOP translates the fonts in the Symbol
font-family...or at least an inconsistency with other user agents I tried, in
particular Internet Explorer and FireFox. I tried to dig into the
CodePointMapping class and the magic it's doing on more than one occasion but
c
I've finally resolved Bugzilla #41306 and committed the necessary change
to fix the page order problem:
http://svn.apache.org/viewvc?rev=680820&view=rev
For the other issues: I don't currently have time (or enough of an itch)
to debug these problems. Of course, we're always happy to review good
pa
I don't see the problem. With both 0.94 and 0.95 FOP does exactly what
you tell it to do. There's a 1pt border between lines 2 & 3 when I run
your snippet.
On 29.07.2008 16:02:21 Laurent Morel wrote:
> Hello,
>
> I have a strange behaviour for table rendering, which I can't explain.
> See example
On 29.07.2008 18:35:33 Griffin,Sean wrote:
> I think there's an issue in how FOP translates the fonts in the Symbol
> font-family...or at least an inconsistency with other user agents I
> tried, in particular Internet Explorer and FireFox. I tried to dig
> into the CodePointMapping class and the m
On 28.07.2008 21:03:09 Andreas Delmelle wrote:
> On Jul 28, 2008, at 18:03, Matthieu Siggen wrote:
>
> Hi
>
> FWIW:
>
> >>> While debugging I found out that the fopFactory.newFop call
> >>> obtains the
> >>> handle. Unfortunately, the handle seems to be arbitrarly
> >>> released, ie. a
> >>>
>> For example, the 'q' character (0x71)
>> should map to the 'θ' character (0x03B8) when Symbol is the
>> font-family, but, if I remember correctly, it simply prints as '#'
>> because 0x71 isn't in the glyph set for the Symbol font.
What I said here was a little misstated. What I meant to say
Thank you for your attention.
I've tried with 0.94 and it works fine.
Problem appears only with 0.95beta
(and I need this last version since it corrects
i-don't-remember-which-problem).
Which 0.95 version do you use ?
Jeremias Maerki a écrit :
I don't see the problem. With both 0.94 and 0.95
Ooops, you're right. That was a bug in 0.95beta. It is fixed in the 0.95
branch: https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/fop-0_95
I really need to find time to prepare the 0.95 final release at some
point. Priorities. Grmbl...
On 30.07.2008 08:04:52 Laurent Morel wrote:
> Thank
12 matches
Mail list logo