[Manuel]
I am currently looking at adding the missing background and
border/padding support to fo:character and have run into a co-ordinate
system issue. In fop text areas and character areas are positioned in
the bpd direction using the offset attribute which refers to the
character
What is the correct amount of baseline shift to apply for sub and super
scripts? Batik seems to use +/- 0.5 * ascender height. Is that the
common way of doing it? The spec says only: The offset ... is
determined using the font data for the nominal font.
Thanks
Manuel
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36677.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
On Fri, 16 Sep 2005 02:58 pm, Finn Bock wrote:
[Manuel]
I am currently looking at adding the missing background and
border/padding support to fo:character and have run into a
co-ordinate system issue. In fop text areas and character areas are
positioned in the bpd direction using the
It's probably easiest for now to do as Batik does. However, Type 1 fonts
provide information about sub and super scripts (size and placement) in
the PFM file. That data is currently not parsed. I assume there's
something similar in TrueType. So ideally, the font would supply the
information how
Vincent,
does FOray font expose this type of information Jeremias described
below?
Manuel
On Fri, 16 Sep 2005 03:36 pm, Jeremias Maerki wrote:
It's probably easiest for now to do as Batik does. However, Type 1
fonts provide information about sub and super scripts (size and
placement) in the
AFAICS, no, it doesn't do that, yet.
On 16.09.2005 09:39:55 Manuel Mall wrote:
Vincent,
does FOray font expose this type of information Jeremias described
below?
Manuel
On Fri, 16 Sep 2005 03:36 pm, Jeremias Maerki wrote:
It's probably easiest for now to do as Batik does. However,
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36678.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
This is probably a question for Luca.
if we have a baseline-shift, eg.
some Xfo:inline font-size=smaller
baseline-shift=super2/fo:inline ...
how is that intended to be modelled with respect to the lead,height, and
middle values to be stored in the created KnuthInlineBoxes for the
fo:inline?
wrap-option is one of those few properties which work in 0.20.5 but are
not yet available in FOP Trunk. Luca, what do you think how difficult it
would be to implement it at least for, let's say, fo:block? I imagine it
would suffice to trick the breaker into not choosing any break
possibilities
On Sep 15, 2005, at 16:05, Jeremias Maerki wrote:
Jeremias,
Ok, let me then explicitely state that my previous mail contained my
own
interpretation and no facts. IMO there are certain gaps and
inaccuracies
in the spec and I tried to take my own expectations and create an
interpretation that
On 16.09.2005 11:43:37 Andreas L Delmelle wrote:
On Sep 15, 2005, at 16:05, Jeremias Maerki wrote:
Jeremias,
Ok, let me then explicitely state that my previous mail contained my
own
interpretation and no facts. IMO there are certain gaps and
inaccuracies
in the spec and I tried
[Jeremias and Andreas on starts-row ends-row]
My take is that only a true value is used to determine a change in
row. It makes no difference to the fo-tree or to layout if a default
false or an explicit false is found.
[7.26.15]
The starts-row and ends-row properties with a true value are
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project xml-fop-maintenance has an issue affecting its community integration.
This issue
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project xml-fop-maintenance has an issue affecting its community integration.
This issue
Jeremias Maerki wrote:
wrap-option is one of those few properties which work in 0.20.5 but are
not yet available in FOP Trunk. Luca, what do you think how difficult it
would be to implement it at least for, let's say, fo:block? I imagine it
would suffice to trick the breaker into not choosing
Manuel Mall wrote:
if we have a baseline-shift, eg.
some Xfo:inline font-size=smaller
baseline-shift=super2/fo:inline ...
how is that intended to be modelled with respect to the lead,height, and
middle values to be stored in the created KnuthInlineBoxes for the
fo:inline?
I think that
On Sep 16, 2005, at 12:15, Jeremias Maerki wrote:
Absolutely no resentment here. I'm sorry for sending the wrong signals.
I simply realized that I was not clear enough that the stuff I wrote is
just my opinion. Stuff like that always happens if I don't want to lose
too much time. Sigh.
Ok,
On 16.09.2005 13:09:05 Luca Furini wrote:
Jeremias Maerki wrote:
wrap-option is one of those few properties which work in 0.20.5 but are
not yet available in FOP Trunk. Luca, what do you think how difficult it
would be to implement it at least for, let's say, fo:block? I imagine it
No idea what this is suddenly about. Looks like a permission problem?
Strange though that it's only the maintenance branch that fails and not
the trunk, too. Any ideas how to resolve?
On 16.09.2005 12:51:17 Sam Ruby wrote:
To whom it may engage...
This is an automated request, but not
[EMAIL PROTECTED] wrote:
Author: lfurini
Date: Fri Sep 16 06:24:16 2005
New Revision: 289531
URL: http://svn.apache.org/viewcvs?rev=289531view=rev
Log:
Implemented the wrap-option property.
The overflow property is not yet implemented, so at the moment if wrap-option =
no-wrap and the text
Chris Bowditch wrote:
[EMAIL PROTECTED] wrote:
Author: lfurini
Date: Fri Sep 16 06:24:16 2005
New Revision: 289531
URL: http://svn.apache.org/viewcvs?rev=289531view=rev
Log:
Implemented the wrap-option property.
The overflow property is not yet implemented, so at the moment if
wrap-option
Still waiting for some feedback here from others. I am reluctant to
change the interface to the renderers without other committers agreeing
because such a change affects every renderer out there. On the other
hand it feels a bit like a kludge to treat/represent fo:character ...
character=x /
On Sep 16, 2005, at 12:26, Finn Bock wrote:
My take is that only a true value is used to determine a change in
row. It makes no difference to the fo-tree or to layout if a default
false or an explicit false is found.
FWIW: That was precisely my understanding too, hence my speaking of a
Luca Furini wrote:
Chris Bowditch wrote:
Hmmm I hate to be the bearer of bad news. But it seems that the
change has broken text-align=right when used on table cells. All the
regression tests pass, so I guess it working when text-align=right
for regular blocks.
D'oh!
Could you please
On Sep 16, 2005, at 16:00, Andreas L Delmelle wrote:
Well, currently you both got me convinced about this. I'm working on
it --but a bit frustrated, since that was really the *only* case where
it failed. All other situations are handled nicely including
row-spans... --even when a user would
Manuel Mall wrote:
Still waiting for some feedback here from others. I am reluctant to
change the interface to the renderers without other committers agreeing
because such a change affects every renderer out there. On the other
hand it feels a bit like a kludge to treat/represent fo:character
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36625.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
On Fri, 16 Sep 2005 10:39 pm, Chris Bowditch wrote:
Manuel Mall wrote:
Still waiting for some feedback here from others. I am reluctant to
change the interface to the renderers without other committers
agreeing because such a change affects every renderer out there. On
the other hand it
On 16.09.2005 16:19:43 Chris Bowditch wrote:
Luca Furini wrote:
Chris Bowditch wrote:
Hmmm I hate to be the bearer of bad news. But it seems that the
change has broken text-align=right when used on table cells. All the
regression tests pass, so I guess it working when
Jeremias Maerki wrote:
The problem is the margin-right which establishes an end-indent. In the
first table the end-indent is reset to 0mm on the table-body. You're not
doing that in the second table. Therefore you get an inherited
end-indent of 10mm in the second table and that's why the text
I'm not a specialist on typography, yet, but the character wrapping
(your option a) sounds definitely like a hack. I've started reading the
parts in the spec about baselines and that's not a casual read. But I
think that at one point we need to handle baselines and all these little
details. I'm
On Fri, 16 Sep 2005, Jeremias Maerki [EMAIL PROTECTED] wrote:
No idea what this is suddenly about. Looks like a permission
problem?
No, the file simply doesn't exist. The properties directory is empty,
at least after the build has finished.
Stefan
On Fri, Sep 16, 2005 at 09:42:01PM +0800, Manuel Mall wrote:
On Fri, 16 Sep 2005 07:10 pm, Luca Furini wrote:
Manuel Mall wrote:
Would be really nice to get some wider variety of fonts to play with.
May be including some unusual scripts with strange baselines. Do we
need something like
34 matches
Mail list logo
