As all of the table FOs are direct descendants of FObj this is a
reasonable thought. Might really be worthwhile.
On 25.08.2005 21:45:16 Andreas L Delmelle wrote:
Hi all,
Has anyone ever thought about introducing an abstract class for
table-related FOs, say TableFObj, that would be extended
On 26.08.2005 09:09:45 Finn Bock wrote:
[Andreas L Delmelle]
Any hint appreciated.
I have added support for the default values in a TableBorderPrecedence
property maker class.
Cool. It's so good to see names other than mine on the commits list.
Since I have added a new file to SVN
Finn Bock wrote:
[Andreas L Delmelle]
Any hint appreciated.
I have added support for the default values in a TableBorderPrecedence
property maker class.
Since I have added a new file to SVN must I do something to make line
ending right?
Yes you need to set the SVN property
The spec says: The percentage is calculated with respect to the
corresponding dimension of the closest area ancestor that was generated
by a block-level formatting object. If that dimension is not specified
explicitly (i.e., it depends on content's
block/inline-progression-dimension), the value is
On 25.08.2005 18:10:51 Victor Mote wrote:
Victor Mote wrote (August 8):
Manuel Mall wrote:
Regarding the bolder, lighter issue and the general
font selection
I looked at the pre-patch for FOrayFont adaptation to Fop
(http://issues.apache.org/bugzilla/show_bug.cgi?id=35948)
On 26.08.2005 10:41:31 Manuel Mall wrote:
The spec says: The percentage is calculated with respect to the
corresponding dimension of the closest area ancestor that was generated
by a block-level formatting object. If that dimension is not specified
explicitly (i.e., it depends on content's
On Fri, 26 Aug 2005 05:14 pm, Jeremias Maerki wrote:
On 26.08.2005 10:41:31 Manuel Mall wrote:
The spec says: The percentage is calculated with respect to the
corresponding dimension of the closest area ancestor that was
generated by a block-level formatting object. If that dimension is
On Fri, 26 Aug 2005 06:00 pm, Finn Bock wrote:
[Manuel Mall]
The spec says: The percentage is calculated with respect to the
corresponding dimension of the closest area ancestor that was
generated by a block-level formatting object. If that dimension is
not specified explicitly (i.e., it
Finn Bock wrote:
It sounds just like a job for the property system since it already deals
with the corresponding properties and knows if a property is explicitly
set.
I don't think that there is an existing way to check if a fo is
block-level but that can be added (like
I'm sorry, I'd better shut up if I can't dive fully into this matter.
I'm just wasting your and my time. Finn seems to have a better grip on
this area.
On 26.08.2005 11:21:58 Manuel Mall wrote:
On Fri, 26 Aug 2005 05:14 pm, Jeremias Maerki wrote:
On 26.08.2005 10:41:31 Manuel Mall wrote:
There is a layout problem with fo:page-number and fo:page-number-citation,
already pointed out but still unresolved.
I think, these formatting objects are very similar, even if their actual
handling is quite different: they both must be replaced by an information
(a page number) that is (or
Jeremias Maerki wrote:
I believe that font-stretch has to included just like
font-weight to select the actual font.
Sorry to be unclear. I understand that font-stretch must be included. The
issue is whether the wider and narrower constraints can be processed in
the FOTree by simply bumping
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=36379.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=36379.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=36379.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=36379.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=36379.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Luca Furini wrote:
snip/
The computation, in itself, is easy, as the LineLM already has all the
necessary information: line width, unadjusted width, available stretch
and shrink.
I think shrinking/stretching the spaces in the case where the guessed
space doesnt match the actual is an
Victor Mote a écrit :
I am ignoring font-stretch for now. I am unclear whether it works similarly
to font-weight, or whether it is totally resolvable in the FO Tree.
Interestingly, CSS 2.1 (the only version of CSS 2 still available at W3C)
removes font-stretch entirely!!??!!
As I understand
Luca Furini wrote:
Yes, undoubtedly a two-pass rendering would produce a better output: and
after all, even LaTex needs to be run twice if there are page number
citations.
Backtracking with some attempts to minimize the scope for
re-layout should be enough, though somewhat less
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=36391.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=36391.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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=36391.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Ok, so from what I understand you want to do, I think that what the
Lenya project did looks good.
http://lenya.apache.org/
What do you think ?
Patrick Paul
Jeremias Maerki wrote:
While we're at it: In preparation for the first release we need to start
thinking about a refactoring of our
I have figured out how the documentation files work and how to edit
them. I still have to figure out how to get the site to build on my
local machine and then I will be in business.
What way you suggest I send the changes to you ?
Thanks,
Patrick Paul
Jeremias Maerki wrote:
Very cool!
25 matches
Mail list logo