You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Andrejus Chaliapinas <a....@infosana.com> on 2006/10/03 15:02:28 UTC
Question on protected Logger member in some classes
Hi,
While trying to debug some changes I've made wtih layout managers I've
noticed that some classes have Logger as protected but not private member?
What is the rationale here - just easy later inheritance of logger or
anything else? For me it seems that logger purpose is to exactly identify
the class, which makes some output and thus shown by name and not see some
parent class name in output. What do you think? How about changing that
current protected to private?
Thank you,
Andrejus
RE: Do we have Area Tree construction also via getNextKnuthElements methods or mostly via addAreas?
Posted by Andrejus Chaliapinas <a....@infosana.com>.
> Andrejus, I think it's best if you read all the threads here on fop-dev
> on auto table layout during August if have not already done so. They
> contain a lot of information about the next steps for the auto table
> layout and what has been discussed so far.
Ok, thank you for pointing to right place as well as for additional comments
on LMs. Will try my best during upcoming week.
Andrejus
Re: Do we have Area Tree construction also via getNextKnuthElements methods or mostly via addAreas?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Well, given that I wrote most of the new table layout code I'd be the
one who knows exactly how it works (or at least I'm supposed to know).
Anyway, at the moment I don't know what exactly I can contribute to get
Andrejus better on his way. For getting the auto table layout feature
right, you don't need to know too much about the inner workings of the
table layout managers.
Also, don't concern yourself to much with the area tree while trying to
understand table layout. The area tree is only the last step.
The thing to focus on are the element lists created by LineLayoutManager.
If you look at the current auto table patch you'll see which classes are
really affected in the "table" package: TableLM and TableCellLM. No need
to dive into TableContentLM or TableStepper which are complex beasts.
Andrejus, I think it's best if you read all the threads here on fop-dev
on auto table layout during August if have not already done so. They
contain a lot of information about the next steps for the auto table
layout and what has been discussed so far.
http://www.nabble.com/-GSoC--Auto-table-layout-questions-tf1933306.html
http://www.nabble.com/Q%3A-Line-layout--%3E-separating-element-list-creation---line-breaking-tf2148860.html
On 05.10.2006 14:54:50 Simon Pepping wrote:
> On Wed, Oct 04, 2006 at 11:18:22PM +0300, Andrejus Chaliapinas wrote:
> > But that still doesn't answer the question - if there are some Knuth
> > elements constructed - what is the best way to debug current Area Tree,
> > which contains them? And if there any mechanism to protect particular Area
> > Tree leafes (or graphs/branches) from additional restructure. Sorry if it's
> > out of context, i.e. we should never bother with such kind of protection
> > cause Knuth elements are pushed there during their processing.
>
> If you want to study the area tree that is created, use the area tree
> output, command line option -at outfile: representation of area tree
> as XML (outfile req'd).
>
> Protecting the area tree or parts thereof is not relevant. The area
> tree is only constructed once.
>
> First the FO tree is constructed. Then the tree of LayoutManagers is
> constructed. These construct the Knuth elements. Then the Line or Page
> Breaker does its work. Then the LMs resume and construct the areas,
> according to the line and page breaking results and according to the
> content of their FOs, for which the Knuth elements contain
> pointers. The PageSequenceLM directs the page layout process, the
> LineLMs direct the paragraph layout process. The latter also happens
> in the table cells. I believe the TableLM directs the whole layout
> process of a table. This is where you want to enable auto table
> layout. But I am not aware of all details of table layout. I hope
> other FOP developers are able to help you.
>
> Regards, Simon
>
> --
> Simon Pepping
> home page: http://www.leverkruid.eu
Jeremias Maerki
Re: Do we have Area Tree construction also via getNextKnuthElements
methods or mostly via addAreas?
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Wed, Oct 04, 2006 at 11:18:22PM +0300, Andrejus Chaliapinas wrote:
> But that still doesn't answer the question - if there are some Knuth
> elements constructed - what is the best way to debug current Area Tree,
> which contains them? And if there any mechanism to protect particular Area
> Tree leafes (or graphs/branches) from additional restructure. Sorry if it's
> out of context, i.e. we should never bother with such kind of protection
> cause Knuth elements are pushed there during their processing.
If you want to study the area tree that is created, use the area tree
output, command line option -at outfile: representation of area tree
as XML (outfile req'd).
Protecting the area tree or parts thereof is not relevant. The area
tree is only constructed once.
First the FO tree is constructed. Then the tree of LayoutManagers is
constructed. These construct the Knuth elements. Then the Line or Page
Breaker does its work. Then the LMs resume and construct the areas,
according to the line and page breaking results and according to the
content of their FOs, for which the Knuth elements contain
pointers. The PageSequenceLM directs the page layout process, the
LineLMs direct the paragraph layout process. The latter also happens
in the table cells. I believe the TableLM directs the whole layout
process of a table. This is where you want to enable auto table
layout. But I am not aware of all details of table layout. I hope
other FOP developers are able to help you.
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.eu
RE: Any thoughts on something like fo:tab support?
Posted by Andrejus Chaliapinas <a....@infosana.com>.
> Ok, I can see why you would want tabs here. Tables are probably a little
> overkill here. What I would do in this case is to use list-block and
> count characters in the title column. I'd set the
> provisional-distance-between-starts property depending on the number of
> characters.
Yes, list-block could probably help in that situation. But I don't have
title column (though not sure what you mean by title column). Why do I need
to count characters in it?
Actually it would be much better to have some FO xml snippet in list.fo
example, which demonstrates how list items will be aligned if we have list
like this:
1.<some space>Item1
1.1.<some space>Item11
1.1.1.<some space>Item111
having each time <some space> length calculation performed based already on
label length to the left of it.
In my case I get that provisional-distance-between-starts value should be
calculated separatedly for each list label-item pair, cause setting it to
some average/maximum value (for title column?) and folowing then by other
label-item pairs doesn't resolve this issue.
Andrejus
RE: Any thoughts on something like fo:tab support?
Posted by Andrejus Chaliapinas <a....@infosana.com>.
Jeremias,
> I'd set the
> provisional-distance-between-starts property depending on the number of
> characters. You won't get the exact same effect but I think it should be
> near enough with little effort in XSLT and no hacking into FOP,
> introducing a feature that's difficult to implement and completely
> non-standard.
I can't achieve my goal in a stable matter with list blocks, cause
provisional-distance-between-starts value depends ahead of text length to be
used for label and having then same provisional-label-separation still
doesn't help to properly align text left.
Why such natural requirement of tab stops is not included in FO?
And another thought on fo:leader. There is nice feature of it like
leader-alignment="reference-area". The only enhancement needed for my case
is to have additional attribute for it like
right-align-at-nearest-tab="0.5in" instead of max=100% and then it should be
not so hard to calculate that position (I don't see any difference actually
with calculation case of max=100%).
What do you think?
Andrejus
Re: Any thoughts on something like fo:tab support?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Ok, I can see why you would want tabs here. Tables are probably a little
overkill here. What I would do in this case is to use list-block and
count characters in the title column. I'd set the
provisional-distance-between-starts property depending on the number of
characters. You won't get the exact same effect but I think it should be
near enough with little effort in XSLT and no hacking into FOP,
introducing a feature that's difficult to implement and completely
non-standard.
On 09.11.2006 10:48:38 Andrejus Chaliapinas wrote:
> > Maybe if you illustrated your problem with some visuals we could give a
> > few suggestions. I'm pretty sure your problem can be solved without tabs.
>
> Ok, here is my very simple visualization (+ sign is used to mark default tab
> stop position).
>
>
> ----+----+----+----+----+----+----+
> blabla: text1 after tab stop
> blablabla: text2 after tab stop
>
> Could this be solved with tables/leaders?
>
> Let say if default tab step is 0.5 inch, then text1 starts here at position
> of 1inch and text2 at 1.5inch in this sample, cause label 'blablabla:' ends
> right after 1inch position, so another nearest one of 1.5inch is taken.
Jeremias Maerki
Re: Any thoughts on something like fo:tab support?
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> Just be prepared that they may wrinkle their noses.
I'd expect them to do exactly this. How should tabs mix with, say,
centered text, or BIDI stuff? I'm not convinced it's worth the
additional complexity of the spec.
J.Pietschmann
RE: Any thoughts on something like fo:tab support?
Posted by Andrejus Chaliapinas <a....@infosana.com>.
Jeremias,
> You can also
> place your wish/requirement for tabs there so it can be considered for
> XSL-FO 2.0. Just be prepared that they may wrinkle their noses.
> [1] http://lists.w3.org/Archives/Public/xsl-editors/
Thank you for pointing there. I'll try to post my feature request.
> Is it? I'm not so sure. You can view it this way: What HTML/CSS is for
> the browser, XSL-FO is for the paper. XSL-FO is even reusing many
> aspects of CSS which says a lot.
That reuse was in my mind when I've checked that old document called "Tab
Stops for CSS" dated of 1997:
http://www.w3.org/People/howcome/t/970224HTMLERB-CSS/WD-tabs-970117.html
Don't know though what happened later.
Thank you very much for your help!
Andrejus
Re: Any thoughts on something like fo:tab support?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 13.11.2006 11:06:51 Andrejus Chaliapinas wrote:
> Jeremias,
>
> > In this case, if the XML format is fixed and cannot be changed at the
> > source, I don't think that XSL-FO is capable of rendering this content.
> > I'd check if you can't change the XML format to process in the first
> > place. If not, I wouldn't use XSL-FO but another format which supports
> > type-writing style, like ODF (OpenOffice) or Word XML (MS Word), to
> > create the documents in PDF format.
>
> My XML format is fixed, so from your statement it seems that XSL-FO is not
> suitable then at all for such type of conversion and especially into PDF
> format.
Yes. There are a lot of things you cannot do with XSL-FO although it is
already that complex. And frankly, I got sick (as a FOP developer) when
I saw all the requirements and wishes for XSL-FO 2.0. Still, custom
solutions for certain areas will always have their market.
> Any plans to enhance it in that type-writer-style text support
> direction?
I was at the W3C's requirements gathering workshop for XSL-FO 2.0 last
month and type-writer-style content has not come up if I remember
correctly. Unfortunately, the minutes are not yet available.
> The main value for me of XSL-FO is its pure Java nature.
Huh? XSL-FO has absolutely nothing to do with Java. FOP just happens to
be implemented in Java.
> Yes, you
> are right that HTML doesn't have tab stops support, but that is different
> story I think.
Is it? I'm not so sure. You can view it this way: What HTML/CSS is for
the browser, XSL-FO is for the paper. XSL-FO is even reusing many
aspects of CSS which says a lot.
Look, if you really want to know why no tab characters are specified in
XSL-FO, ask the XSL-FO working group [1]. I can only guess. You can also
place your wish/requirement for tabs there so it can be considered for
XSL-FO 2.0. Just be prepared that they may wrinkle their noses.
[1] http://lists.w3.org/Archives/Public/xsl-editors/
> I've tested Andreas approach with tables and column numbers/spans but later
> found it as very particular font specific (correct chars per tab calculation
> having in mind possible different text styles is almost equal to the task of
> space leader length calculation between 2 parts separated by tab stop - at
> least it seems so for me).
>
> Thank you,
> Andrejus
Jeremias Maerki
RE: Any thoughts on something like fo:tab support?
Posted by Andrejus Chaliapinas <a....@infosana.com>.
Andreas,
Thanks a lot for your XSL sample. I'll try to play around it during upcoming
week. Quick test on it so far showed me that line 3 from my original sample:
----+----+----+----+
blabla: text3 after 2 tabs
and this XML corresponding to it:
<par>
blabla:
<tab />
<tab />
text3 after 2 tabs
</par>
was converted to:
<fo:table-row>
<fo:table-cell number-columns-spanned="2"
column-number="1">
<fo:block>blabla:</fo:block>
</fo:table-cell>
<fo:table-cell number-columns-spanned="8"
column-number="2">
<fo:block>text3 after 2 tabs</fo:block>
</fo:table-cell>
</fo:table-row>
though I think number-columns-spanned should be equal 3 for the label part
and column-number equal 3 for text part in this case.
Anyway, this is really good basis to extend/enhance.
Now I have a lot of work ahead on this.
Andrejus
Re: Any thoughts on something like fo:tab support?
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Nov 12, 2006, at 13:25, Jeremias Maerki wrote:
> Ok, so you don't just have a simple list of name/value pairs that
> happen
> to be separated by a tab element. You rather have arbitrary
> type-writer-style text. That makes it a lot more complicated, at least
> for XSL-FO.
Well, I've already been playing a bit with it yesterday, and found
out that the only really 'complicated' parts are
a) determining/guessing the number of characters per tab.
FTM, suppose this is a constant, and we put it in a global
variable: chars-per-tab.
(but this can easily be replaced by a template parameter which is
passed down)
b) depending on the answer to the question whether there can be more
than two 'columns' per par,
determining the number-columns-spanned can also become
increasingly difficult for all but the first text node
WRT b), what I'm referring to is the possibility of par nodes like this:
<par>
blabla:
<tab />
more text more text
<tab />
<tab />
some more text
</par>
This type of par does not occur in Andrejus' example. If there is
always at most one 'label' and one 'item' separated by an arbitrary
number of tabs, then it is not too difficult to solve in XSLT.
('label' = first text node in a par; 'item' = a sequence of text()
and break nodes)
In that case, the trick seems to be to apply templates only to the
text() nodes, and using the preceding-sibling tabs to determine the
right column-number to set.
Take control by starting the transform by applying templates only to
the first text node in each par ( a par node will correspond to a row
in the output ). Take care to add an xsl:strip-space, to avoid
processing white-space-only text nodes.
This would only be reliable, of course, when using non-proportional
fonts, and supposing default linefeed- and white-space-treatment.
After processing this first text node, check for
following-sibling::text()[1][not(preceding-sibling::*[1][name(.)
='break'])]
If true, also check for tab nodes in between the current text node
and that following-sibling.
From that and the number of columns spanned by the current cell, you
can then calculate the next column-number and pass that as a
parameter into the template applied to the following-sibling::text()[1].
After processing each text node, check for following-sibling::node()
[1][name(.)='break']. If this evaluates to true, apply templates to
that break (which will do no more than create a new block for its
immediately following text node in the current cell)
The matching template for the break nodes will also perform a similar
check for following-sibling breaks, and create a new block for them...
Complete stylesheet code below. Put the source supplied by Andrejus
in one <text> node, and it can be transformed with this code into a
table structure.
No guarantees that it will cover all possibilities, but it may
already offer Andrejus some idea on how to achieve this.
Cheers,
Andreas
---
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/
Transform" xmlns:fo="http://www.w3.org/1999/XSL/Format">
<xsl:strip-space elements="*" />
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes" />
<xsl:template match="/text">
<xsl:param name="tab-width" select="'0.5in'" />
<xsl:param name="max-tabs" select="9" />
<fo:table width="100%" table-layout="fixed">
<fo:table-column column-width="{$tab-width}" number-columns-
repeated="{$max-tabs}" />
<fo:table-body>
<xsl:apply-templates select="par">
<xsl:with-param name="chars-per-tab" select="5" />
<xsl:with-param name="max-tabs" select="$max-tabs" />
</xsl:apply-templates>
</fo:table-body>
</fo:table>
</xsl:template>
<xsl:template match="par">
<xsl:param name="chars-per-tab" select="1" />
<xsl:param name="max-tabs" select="40" />
<fo:table-row>
<xsl:apply-templates select="text()[1]">
<xsl:with-param name="chars-per-tab" select="$chars-per-tab" />
<xsl:with-param name="max-tabs" select="$max-tabs" />
</xsl:apply-templates>
</fo:table-row>
</xsl:template>
<xsl:template match="par/text()">
<xsl:param name="chars-per-tab" select="1" />
<xsl:param name="next-colnr" select="0" />
<xsl:param name="max-tabs" select="40" />
<xsl:choose>
<xsl:when test="not(preceding-sibling::text())">
<xsl:variable name="colnr" select="1 + count(preceding-
sibling::tab)" />
<xsl:variable name="colspan" select="1 + floor(string-length
(normalize-space(.)) div $chars-per-tab)" />
<fo:table-cell column-number="{$colnr}" number-columns-
spanned="{$colspan}">
<fo:block>
<xsl:value-of select="normalize-space(.)" />
</fo:block>
<xsl:if test="following-sibling::*[1][name(.)='break']">
<xsl:apply-templates select="following-sibling::break[1]" />
</xsl:if>
</fo:table-cell>
<xsl:if test="following-sibling::text()[1][not(preceding-
sibling::*[1][name(.)='break'])]">
<xsl:apply-templates select="following-sibling::text()[1]">
<xsl:with-param name="next-colnr" select="$colnr +
$colspan - 1" />
<xsl:with-param name="max-tabs" select="$max-tabs" />
</xsl:apply-templates>
</xsl:if>
</xsl:when>
<xsl:otherwise>
<fo:table-cell column-number="{$next-colnr}" number-columns-
spanned="{$max-tabs - $next-colnr + 1}">
<fo:block>
<xsl:value-of select="normalize-space(.)" />
</fo:block>
<xsl:if test="following-sibling::*[1][name(.)='break']">
<xsl:apply-templates select="following-sibling::break[1]" />
</xsl:if>
</fo:table-cell>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
<xsl:template match="break">
<fo:block>
<xsl:value-of select="normalize-space(following-sibling::text()
[1])" />
</fo:block>
<xsl:if test="following-sibling::*[1][name(.)='break']">
<xsl:apply-templates select="following-sibling::break[1]" />
</xsl:if>
</xsl:template>
</xsl:stylesheet>
---
Re: Any thoughts on something like fo:tab support?
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Nov 13, 2006, at 11:06, Andrejus Chaliapinas wrote:
> <snip />
> I've tested Andreas approach with tables and column numbers/spans
> but later
> found it as very particular font specific (correct chars per tab
> calculation
> having in mind possible different text styles is almost equal to
> the task of
> space leader length calculation between 2 parts separated by tab
> stop - at
> least it seems so for me).
Yep. That's what I meant by 'it will only be reliable in case of non-
proportional fonts', and even then there's the possibility of a
simple bold (or bolder) font-weight, but also --far more
complicated-- I imagine things like kerning and letter-spacing could
wreck the game, unfortunately.
It's really only suited for simple transformations of tabulated plain-
text to, for example, a Courier font (where the number of characters
per tab stop is easy/straightforward to predict).
Oh well, it was worth a try :)
Cheers,
Andreas
RE: Any thoughts on something like fo:tab support?
Posted by Andrejus Chaliapinas <a....@infosana.com>.
Jeremias,
> In this case, if the XML format is fixed and cannot be changed at the
> source, I don't think that XSL-FO is capable of rendering this content.
> I'd check if you can't change the XML format to process in the first
> place. If not, I wouldn't use XSL-FO but another format which supports
> type-writing style, like ODF (OpenOffice) or Word XML (MS Word), to
> create the documents in PDF format.
My XML format is fixed, so from your statement it seems that XSL-FO is not
suitable then at all for such type of conversion and especially into PDF
format. Any plans to enhance it in that type-writer-style text support
direction? The main value for me of XSL-FO is its pure Java nature. Yes, you
are right that HTML doesn't have tab stops support, but that is different
story I think.
I've tested Andreas approach with tables and column numbers/spans but later
found it as very particular font specific (correct chars per tab calculation
having in mind possible different text styles is almost equal to the task of
space leader length calculation between 2 parts separated by tab stop - at
least it seems so for me).
Thank you,
Andrejus
Re: Any thoughts on something like fo:tab support?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Ok, so you don't just have a simple list of name/value pairs that happen
to be separated by a tab element. You rather have arbitrary
type-writer-style text. That makes it a lot more complicated, at least
for XSL-FO.
In this case, if the XML format is fixed and cannot be changed at the
source, I don't think that XSL-FO is capable of rendering this content.
I'd check if you can't change the XML format to process in the first
place. If not, I wouldn't use XSL-FO but another format which supports
type-writing style, like ODF (OpenOffice) or Word XML (MS Word), to
create the documents in PDF format.
You asked earlier:
> Why such natural requirement of tab stops is not included in FO?
As I said, it was a concious decision by the XSL working group. I tried
to find their reasoning as I remember having read about it somewhere a
long time ago. But unfortunately, I couldn't find it anymore. Does HTML
have tab support? No, either, probably because of the same reasons. If
you wanted to convert your XML file to HTML, you'd have the same problem.
On 11.11.2006 10:04:07 Andrejus Chaliapinas wrote:
> Andreas,
>
> > Can you show us the non-transformed source nodes for those lines?
> > The tab-stops, I presume, correspond to some marker in the source XML
> > (a tab character?).
>
> Here is how that corresponding to my sample XML looks like:
>
> <par>
> blabla:
> <tab />
> text1 after one tab
> </par>
> <par>
> blablabla:
> <tab />
> text2 after one tab
> </par>
> <par>
> blabla:
> <tab />
> <tab />
> text3 after 2 tabs
> </par>
> <par>
> <tab />
> blabla:
> <tab />
> text4 when one tab exists before label and another it
> </par>
> <par>
> <tab />
> blabla:
> <tab />
> text5 first line
> <break />
> text6 second line
> <break />
> text7 third line
> </par>
>
>
> <par> means here new paragraph, so it's easy to convert it to fo:block or
> fo:inline
> <tab> means default tab stop, so following text should be positioned at the
> nearest 0.5 inch position
> <break> means line break inside paragraph (like shift+enter in text editors)
>
> Hope this could help for thinking - I'll really appreaciate that from you
> actually.
>
> Maybe you could show me another XSL sample, in which second line of my
> sample 'blablabla:' occupies not just first cell but also part of second
> cell in the row and then you put some calculated space somehow before text
> will start.
>
> Thank you.
>
> Andrejus
Jeremias Maerki
RE: Any thoughts on something like fo:tab support?
Posted by Andrejus Chaliapinas <a....@infosana.com>.
Andreas,
> Can you show us the non-transformed source nodes for those lines?
> The tab-stops, I presume, correspond to some marker in the source XML
> (a tab character?).
Here is how that corresponding to my sample XML looks like:
<par>
blabla:
<tab />
text1 after one tab
</par>
<par>
blablabla:
<tab />
text2 after one tab
</par>
<par>
blabla:
<tab />
<tab />
text3 after 2 tabs
</par>
<par>
<tab />
blabla:
<tab />
text4 when one tab exists before label and another it
</par>
<par>
<tab />
blabla:
<tab />
text5 first line
<break />
text6 second line
<break />
text7 third line
</par>
<par> means here new paragraph, so it's easy to convert it to fo:block or
fo:inline
<tab> means default tab stop, so following text should be positioned at the
nearest 0.5 inch position
<break> means line break inside paragraph (like shift+enter in text editors)
Hope this could help for thinking - I'll really appreaciate that from you
actually.
Maybe you could show me another XSL sample, in which second line of my
sample 'blablabla:' occupies not just first cell but also part of second
cell in the row and then you put some calculated space somehow before text
will start.
Thank you.
Andrejus
Re: Any thoughts on something like fo:tab support?
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Nov 10, 2006, at 20:18, Andrejus Chaliapinas wrote:
>> That would be the
>> case if you needed different tab-stops for different lines. In the
>> example the tab-stops are all the same
>
> My sample was just the easiest one to get your thoughts on it. But in
> general case I really need to have different tab-stops for different
> lines/blocks.
>
> In general it would be like this:
>
> ----+----+----+----+
> blabla: text1 after one tab
> blablabla: text2 after one tab
> blabla: text3 after 2 tabs
> blabla: text4 when one tab exists before label and another
> after it
> blabla: text5 first line
> text6 second line
> text7 third line
>
> So, as you may see - different tab stops positions are used having
> here each
> default step. But then later I have also the case when each line
> has its own
> tab stops.
I see your point. Still, mine was that the width of the tab-stops is
the same for all rows, making it virtually a grid. You only need to
create separate tables if those widths are different.
Using a table, the problem can be solved rather easily, by setting an
explicit column-number for the first cell in the fourth and later
rows. There is (luckily) no constraint forcing all columns in the row
to be occupied by a cell...
The definition of the columns is very simple:
simplest case
-> one fo:table-column, column-width of 0.5in
number-of-columns-repeated something like floor($region-body-
width / 0.5in)
Can you show us the non-transformed source nodes for those lines?
The tab-stops, I presume, correspond to some marker in the source XML
(a tab character?).
If that is the case, then maybe that could be used to your advantage,
to trigger the creation of explicit column-number attributes on the
fo:table-cells...?
I'm still convinced that this is doable, and not even too complex, in
pure XSL-FO, especially when using XSLT 2.0, though I can't say for
sure without having seen the source nodes.
Cheers,
Andreas
RE: Any thoughts on something like fo:tab support?
Posted by Andrejus Chaliapinas <a....@infosana.com>.
Andreas,
> That would be the
> case if you needed different tab-stops for different lines. In the
> example the tab-stops are all the same
My sample was just the easiest one to get your thoughts on it. But in
general case I really need to have different tab-stops for different
lines/blocks.
In general it would be like this:
----+----+----+----+
blabla: text1 after one tab
blablabla: text2 after one tab
blabla: text3 after 2 tabs
blabla: text4 when one tab exists before label and another after it
blabla: text5 first line
text6 second line
text7 third line
So, as you may see - different tab stops positions are used having here each
default step. But then later I have also the case when each line has its own
tab stops.
And again I think that extension of fo:leader attributes (if you don't want
to introduce any new, though more logically stated, elements) should help to
solve all of that complexity.
Probably I should go then on my own if no one else supports that idea.
Andrejus
Re: Any thoughts on something like fo:tab support?
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Nov 9, 2006, at 10:31, Jeremias Maerki wrote:
Hi Andrejus / Jeremias,
> <snip />
> Besides that I think it would be rather difficult to implement. I'd
> rather not introduce tab stops in FOP. But I don't know what the
> others
> think.
Seems quite awkward to me as well, and only really feasible in case
of blocks of which you know for certain that they will not span
multiple lines. The line-breaking algorithm will become quite
complicated if it has to take into account such tab-stops (if I
esteem correctly).
Using tables, OTOH, would not necessarily be overkill, I think... :/
Starting from a fixed-layout (fixed column-widths, all 0.5in), the
only real effort would be to estimate how many columns the content of
each cell will need. Say at most 1in is needed for the first (but
also more than 0.5in), then its number-columns-spanned property
should get a value of 2. The second cell will then automatically get
column-number of 3, etc.
Apart from that tiny effort in the XSLT code, table-layout will take
care of all the rest without any intervention/ manipulation. It
remains a bit of guess-work, but in the end, I think using a table is
to be preferred over introducing such a non-standard FO.
Andrejus' observation that 'one row of such a table (is) independent
of another' seems to me not really true/accurate. That would be the
case if you needed different tab-stops for different lines. In the
example the tab-stops are all the same, so correspond to what one
could call virtual columns.
HTH!
Cheers,
Andreas
RE: Any thoughts on something like fo:tab support?
Posted by Andrejus Chaliapinas <a....@infosana.com>.
> Maybe if you illustrated your problem with some visuals we could give a
> few suggestions. I'm pretty sure your problem can be solved without tabs.
Ok, here is my very simple visualization (+ sign is used to mark default tab
stop position).
----+----+----+----+----+----+----+
blabla: text1 after tab stop
blablabla: text2 after tab stop
Could this be solved with tables/leaders?
Let say if default tab step is 0.5 inch, then text1 starts here at position
of 1inch and text2 at 1.5inch in this sample, cause label 'blablabla:' ends
right after 1inch position, so another nearest one of 1.5inch is taken.
Re: Any thoughts on something like fo:tab support?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
At any rate, this FO could not be called fo:tab because it's
non-standard and must not be in the fo namespace. ODF uses text:tab-stop
(Namespace URI: urn:oasis:names:tc:opendocument:xmlns:text:1.0).
Something like that could make sense for RTF output in certain
situations (as output element) but definitely not for the other output
formats (as input/control element). If you told your idea to the XSL
working group, they'd probably strangle you. :-) It was a very conscious
decision not to support tabs in XSL-FO.
Besides that I think it would be rather difficult to implement. I'd
rather not introduce tab stops in FOP. But I don't know what the others
think.
Maybe if you illustrated your problem with some visuals we could give a
few suggestions. I'm pretty sure your problem can be solved without tabs.
On 09.11.2006 09:27:05 Andrejus Chaliapinas wrote:
> Hi,
>
> Sorry, I was very busy with other stuff to work on table auto layout (plan
> to return to that next week), but right now another additional issue is
> bothering me - how could I have simple enter form (in which you have column
> of labels and column of aligned input fields) converted? I saw already
> suggestion of using table for that purposes, but it's not suitable for my
> situation, cause I'd like in this case to have mostly one row of such table
> independent from another and making such calculations a little bit ahead is
> difficult.
>
> So, I have proposal (please correct me if it's already decided on similar
> one what to do) to implement something like fo:tab tag, which will at the
> first stage of implementation work mostly like fo:leader, but with
> additional knowledge of what is the default tab step is and will calculate
> where is nearest tab stop should be placed based on the text block sizes
> under processing.
>
> Does it make sense in terms of FOP at all?
>
> Any help would be appreciated.
>
> Andrejus
Jeremias Maerki
Any thoughts on something like fo:tab support?
Posted by Andrejus Chaliapinas <a....@infosana.com>.
Hi,
Sorry, I was very busy with other stuff to work on table auto layout (plan
to return to that next week), but right now another additional issue is
bothering me - how could I have simple enter form (in which you have column
of labels and column of aligned input fields) converted? I saw already
suggestion of using table for that purposes, but it's not suitable for my
situation, cause I'd like in this case to have mostly one row of such table
independent from another and making such calculations a little bit ahead is
difficult.
So, I have proposal (please correct me if it's already decided on similar
one what to do) to implement something like fo:tab tag, which will at the
first stage of implementation work mostly like fo:leader, but with
additional knowledge of what is the default tab step is and will calculate
where is nearest tab stop should be placed based on the text block sizes
under processing.
Does it make sense in terms of FOP at all?
Any help would be appreciated.
Andrejus
Re: Do we have Area Tree construction also via getNextKnuthElements methods or mostly via addAreas?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
I doubt anyone currently has much time to write such documentation. Yes,
the design document on the web is outdated and the Wiki does not contain
an overview of the whole layout engine. That's not so good but reflects
how many resources we have for this project. It requires that we set our
priorities on the absolutely necessary. Sorry. Simon once wrote some
extensive documentation about the layout engine, but that applied to the
design before the switch to the Knuth element model.
On 05.10.2006 14:29:28 Andrejus Chaliapinas wrote:
> > J.Pietschmann wrote:
> > > Simon Pepping wrote:
> > >> No UML diagrams for FOP available. Would be nice though.
> > >
> > > As soon as I get some spare time, I'll try
> > > http://sourceforge.net/projects/umldot
> > > I suspect the diagrams to be somewhat unwieldy.
> > >
> > > J.Pietschmann
> > >
> > I think that is not good choice for genetaring UML diags, while
> > http://sourceforge.net/projects/umldot is in version 0.1.0 and no
> > screeenshot. On sourceforge are plenty of abondoned or too new projects
> > to be usable.
>
> Have you tried to use EclipseUML
> (http://eclipse-plugins.2y.net/eclipse/plugin_details.jsp?id=151)?
>
> But again - if someone could write some detailed doc on those LMs
> interactions (I don't see that now in design documents) - I could try and
> generate then those myself.
>
> Andrejus
Jeremias Maerki
RE: Do we have Area Tree construction also via getNextKnuthElements methods or mostly via addAreas?
Posted by Andrejus Chaliapinas <a....@infosana.com>.
> J.Pietschmann wrote:
> > Simon Pepping wrote:
> >> No UML diagrams for FOP available. Would be nice though.
> >
> > As soon as I get some spare time, I'll try
> > http://sourceforge.net/projects/umldot
> > I suspect the diagrams to be somewhat unwieldy.
> >
> > J.Pietschmann
> >
> I think that is not good choice for genetaring UML diags, while
> http://sourceforge.net/projects/umldot is in version 0.1.0 and no
> screeenshot. On sourceforge are plenty of abondoned or too new projects
> to be usable.
Have you tried to use EclipseUML
(http://eclipse-plugins.2y.net/eclipse/plugin_details.jsp?id=151)?
But again - if someone could write some detailed doc on those LMs
interactions (I don't see that now in design documents) - I could try and
generate then those myself.
Andrejus
Re: Do we have Area Tree construction also via getNextKnuthElements
methods or mostly via addAreas?
Posted by Tomas Studva <ts...@gmail.com>.
J.Pietschmann wrote:
> Simon Pepping wrote:
>> No UML diagrams for FOP available. Would be nice though.
>
> As soon as I get some spare time, I'll try
> http://sourceforge.net/projects/umldot
> I suspect the diagrams to be somewhat unwieldy.
>
> J.Pietschmann
>
I think that is not good choice for genetaring UML diags, while
http://sourceforge.net/projects/umldot is in version 0.1.0 and no
screeenshot. On sourceforge are plenty of abondoned or too new projects
to be usable.
But it is a good idea to generate it (and UML is lovely). Look here,
maybe Alma is good choice. Also eclipse TPTP can produce graphical
representation of workflow - sequence diagram, but as I know it hasn't
got any good export format.
Tomas
Re: Do we have Area Tree construction also via getNextKnuthElements
methods or mostly via addAreas?
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Simon Pepping wrote:
> No UML diagrams for FOP available. Would be nice though.
As soon as I get some spare time, I'll try
http://sourceforge.net/projects/umldot
I suspect the diagrams to be somewhat unwieldy.
J.Pietschmann
RE: Do we have Area Tree construction also via getNextKnuthElements methods or mostly via addAreas?
Posted by Andrejus Chaliapinas <a....@infosana.com>.
> I do not really know why Patrick created a second TableContentLM. His
> procedure constructs the Knuth elements twice. I suppose that he
> feared that this would have side effects, and that he tried to avoid
> those by doing the first evaluation in another TableContentLM.
>
But that still doesn't answer the question - if there are some Knuth
elements constructed - what is the best way to debug current Area Tree,
which contains them? And if there any mechanism to protect particular Area
Tree leafes (or graphs/branches) from additional restructure. Sorry if it's
out of context, i.e. we should never bother with such kind of protection
cause Knuth elements are pushed there during their processing.
> No UML diagrams for FOP available. Would be nice though.
Well, maybe one day if I'll become familiar enough with whole project I'll
produce one. Probably first it would be just good to have such sequence
described by words, but in FOP Design: Layout document it talks only about
separate LMs, so whole picture is missing.
Andrejus
Re: Do we have Area Tree construction also via getNextKnuthElements
methods or mostly via addAreas?
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Wed, Oct 04, 2006 at 01:59:07PM +0300, Andrejus Chaliapinas wrote:
> Hi,
>
> I'm trying to understand why in Patrick's code, when he deals with Table
> auto layout feature, after TableContentLayoutManager over current
> TableLayoutManager is prepared and processed with required columns
> shrinking/extra space distribution - there is another
> TableContentLayoutManager creation (yes, this was already commeted by
> Jeremias as no go approach)? Is it because something in Area Tree (some part
> of its graph) needs to be reevaluated once more (due to changed column
> width/columnMins/anything else)?
>
> If I comment second construction - then auto table layout testcase (yes
> Manuel, that's why I was focused on them) fails due to incorrect IPDA value
> for the first block presence in resulted area tree xml file.
I do not really know why Patrick created a second TableContentLM. His
procedure constructs the Knuth elements twice. I suppose that he
feared that this would have side effects, and that he tried to avoid
those by doing the first evaluation in another TableContentLM.
> Any help would be appreciated. I think it would be great if we could have
> UML sequence diagram for those LM invocations/dependencies during some
> general table processing.
No UML diagrams for FOP available. Would be nice though.
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.eu
RE: Question on protected Logger member in some classes
Posted by Andrejus Chaliapinas <a....@infosana.com>.
> If anyone else can do that in the meantime, that would be great. There
> are other patches also waiting to be processed.
Probably you are the only man who could do that. There were no responses for
last 4 hours. Hopefully tomorrow.
Andrejus
Do we have Area Tree construction also via getNextKnuthElements methods or mostly via addAreas?
Posted by Andrejus Chaliapinas <a....@infosana.com>.
Hi,
I'm trying to understand why in Patrick's code, when he deals with Table
auto layout feature, after TableContentLayoutManager over current
TableLayoutManager is prepared and processed with required columns
shrinking/extra space distribution - there is another
TableContentLayoutManager creation (yes, this was already commeted by
Jeremias as no go approach)? Is it because something in Area Tree (some part
of its graph) needs to be reevaluated once more (due to changed column
width/columnMins/anything else)?
If I comment second construction - then auto table layout testcase (yes
Manuel, that's why I was focused on them) fails due to incorrect IPDA value
for the first block presence in resulted area tree xml file.
Any help would be appreciated. I think it would be great if we could have
UML sequence diagram for those LM invocations/dependencies during some
general table processing.
Andrejus
Re: Question on protected Logger member in some classes
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
As soon as I have time and write access to the SVN repo. Here at the
Cocoon GetTogether we're having some problems accessing SVN over HTTPS.
If anyone else can do that in the meantime, that would be great. There
are other patches also waiting to be processed.
On 03.10.2006 16:05:48 Andrejus Chaliapinas wrote:
> > You're right. These protected variables are sometimes not ideal. If you
> > change anything to private while you work on the code, that's fine for
> > me.
>
> Could you apply this patch to trunk?
> http://issues.apache.org/bugzilla/attachment.cgi?id=18956
>
> Andrejus
Jeremias Maerki
RE: Question on protected Logger member in some classes
Posted by Andrejus Chaliapinas <a....@infosana.com>.
> You're right. These protected variables are sometimes not ideal. If you
> change anything to private while you work on the code, that's fine for
> me.
Could you apply this patch to trunk?
http://issues.apache.org/bugzilla/attachment.cgi?id=18956
Andrejus
Re: Question on protected Logger member in some classes
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
You're right. These protected variables are sometimes not ideal. If you
change anything to private while you work on the code, that's fine for
me.
On 03.10.2006 15:02:28 Andrejus Chaliapinas wrote:
> Hi,
>
> While trying to debug some changes I've made wtih layout managers I've
> noticed that some classes have Logger as protected but not private member?
> What is the rationale here - just easy later inheritance of logger or
> anything else? For me it seems that logger purpose is to exactly identify
> the class, which makes some output and thus shown by name and not see some
> parent class name in output. What do you think? How about changing that
> current protected to private?
>
> Thank you,
> Andrejus
Jeremias Maerki