feedback on 0.9alpha1
till now all that keep-together that was missing in 0.20.5 and that drove me off (or deferred the using of fop) works good enough for my little project. gerhard -- .''`. gerhard oettl on Debian/Gnu Linux : :' : `. `'` gpg key: 1024D/D59131AA 2002-06-18 `- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
fo:index
is there a workaround or xslt magic[1] or something else to get the funcionality that was described as formating objects for indexing in the working draft for xsl 1.1? particularry the fo:index-page-citation-list was something that would be very usefull for me. [1] i think a lot of page-number-citation objects could do the trick, but if i can avoid that i would prefere. any hints or pointers? are there any plans or a (aproximativ) timeframe when this feature will make it into fop? thanks in advance gerhard -- .''`. gerhard oettl on Debian/Gnu Linux : :' : `. `'` gpg key: 1024D/D59131AA 2002-06-18 `- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fo:index
On Dec 11, 2005, at 10:54, gerhard oettl wrote:
Hi Gerhard,
is there a workaround or xslt magic[1] or something else to get
the funcionality that was described as formating objects for
indexing in the working draft for xsl 1.1?
particularry the fo:index-page-citation-list was something that
would be very usefull for me.
[1] i think a lot of page-number-citation objects could do the
trick, but if i can avoid that i would prefere.
Currently that is the only way to go about it.
To mimic the example given in the XSL 1.1 WD (simplified):
Say you have indextermterm/indexterm in a number of places in
your source XML, then you can define a template like:
xsl:template match=indexterm
fo:wrapper id=concat(.,generate-id(.)) /
/xsl:template
This will create the points the index will refer to.
I think you'll also need to define an xsl:key to group the indexterm
nodes by their value (maybe not necessary for XSLT 2.0, since there
you have the xsl:for-each-group functionality)
xsl:key name=indexterm-by-term match=indexterm use=. /
Then, in your root template, as the very last step, you could create
a new page-sequence and do something like:
xsl:for-each select=//indexterm[generate-id()=
generate-id(key('indexterm-by-term',.)[1])]
xsl:variable name=term select=. /
fo:block
xsl:value-of select=$term /
xsl:text /xsl:text
xsl:for-each select=key('indexterm-by-term',$term)
fo:basic-link internal-destination=concat(.,generate-id(.))
fo:page-number-citation ref-id=concat(.,generate-id(.)) /
/fo:basic-link
xsl:if test=position()!=last()
xsl:text, /xsl:text
/xsl:if
/xsl:for-each
/fo:block
/xsl:for-each
Beware! Untested, so might need quite a bit of tweaking, but IIC,
this is the general idea.
are there any plans or a (aproximativ) timeframe when this
feature will make it into fop?
None that I'm aware of, unfortunately.
HTH!
Cheers,
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Workaround:(How to pass input of xml tranfs...) ?
Hello, I did a thorough search for the bug which prevents the output of my xml transformation to be cleanly transformed with the xsl transformation into the xsl-fo and later into the pdf. It seems that this is related to the parsers in use. It simply does not work to process the output of the xml transformation directly with the xsl document. The xsl document never finds any tags in my original xml file. Is this a bug in sax or in fop? Anyway this problem is an absolute show-stopper for my project. I was looking for a workaround for this problem but so far I can do nothing but work with the XSLTInputHandler and buffer the output of the sax generation in a file on the local filesystem. This is very suboptimal. :o( What are your suggestions should I contact the fop developers on this matter directly or should I use a different approach? If needed I could again post the code of the servlet... Cheers, Pete -- 10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail +++ GMX - die erste Adresse für Mail, Message, More +++ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fo:index
On Sun, Dec 11, 2005 at 10:54:48AM +0100, gerhard oettl wrote: [1] i think a lot of page-number-citation objects could do the trick, but if i can avoid that i would prefere. I forgot to mention, that my main problem is not to get the page-numbers but to supress duplicates. It is a surname index of a chronicle where some surnames are used six to ten times on the same page. I need (currently) _no_ merging in the form: Brown: 8,11-15,18,22 Smith: ... I would be sadisfied with: Brown: 8,11,12,13,14,15,18,22 Smith: ... but i don't want a index with: Brown: 8,11,12,12,12,12,12,12,12,12,12,12,12,13,14,15,18,22 Smith: ... tanks gerhard -- .''`. gerhard oettl on Debian/Gnu Linux : :' : `. `'` gpg key: 1024D/D59131AA 2002-06-18 `- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.90alpha1: content-width=scale-to-fit creates damaged PDF
Ok, guys. Time for me to chime in. I've read through all the messages and have a few things to add: java.lang.RuntimeException: Some content could not fit into a line/page after 50 attempts. Giving up to avoid an endless loop. This messages in our context here says nothing about the image not fitting into the available width, although the message might suggest so. The problem is actually that the image does not fit vertically in the available height. The feature that tries to fit a box into a later page if it doesn't fit into the current page is currently only enabled for page breaking (i.e. vertical direction). The same algorithm is used for line breaking but has this feature currently disabled because we don't have changing available width from line to line as we don't support side-floats, yet. Andreas was right that the broken PDF is a result of the above error message which is actually an exception that stops processing. In general, The error message itself is not a bug. It may simply be that your images are too big to fit into the page. In my tests I found no bugs, only images that didn't fit vertically due to settings on the external-graphic. But that doesn't mean there are no bugs or no missing features in external-graphic(read on) Andreas is right about the bug for scaling=non-uniform, height set and content-height set to scale-to-fit. Jay, if you'd like to help systematic testing here that would be fantastic. Please note that quite a few test cases already exist in test/layoutengine/standard-testcases (everything that starts with external-graphic and instream-foreign-object). Please note that the size calculations for both formatting objects use the same code (AbstractGraphicsLayoutManager) which means that fixing one, fixes the other, too. Having more test cases like the existing ones would be great and is the first important step towards fixing all remaining problems. Concerning your suggestion of a scale-down-to-fit I'd say that this is not necessary provided I've understood your requirement. In theory, I think you'd need to do this: fo:external-graphic src=... inline-progression-dimension.maximum=100% content-width=scale-to-fit/ This will leave inline-progression-dimension.optimum to auto which means the image (viewport) size can adjust itself based on its contents, but only up to the maximum which I specified as 100% of the available width. Due to the scale-to-fit, the image will be painted at 100% size as long as it's no wider than the available width, as if content-width were specified as auto. But as soon as the intrinsic width grows beyong the limit it is scaled down to fit. The only problem: i-p-d.maximum is currently not used in the whole process. I've started to hack something in but realized that it will make some additional refactoring necessary. Not a 5-minute job. The whole calculation gets more complicated all the time. Also, Andreas' bug shows that there are certain cases, that currently aren't handled correctly. So let's better create more test cases before we change anything. Get the whole picture and such... On 11.12.2005 00:52:45 Jay Bryant wrote: I wasn't being very methodical with my earlier testing. Rather, I was pursuing whatever ideas my intuition brought to me. I think a test plan that works all combinations of the width, content-width, height, content-height, and scaling properties (in each unit of measure, too) is in order. I'll see what I can do along that line. Jay Bryant Bryant Communication Services - Original Message - From: Andreas L Delmelle [EMAIL PROTECTED] To: fop-users@xmlgraphics.apache.org Sent: Saturday, December 10, 2005 3:09 PM Subject: Re: 0.90alpha1: content-width=scale-to-fit creates damaged PDF On Dec 10, 2005, at 22:03, Andreas L Delmelle wrote: fo:external-graphic src=... width=auto content-width=auto height=auto content-height=scale-to-fit scaling=non-uniform / Correction: this is OK - width/height = auto means use content-size - content-height=scale-to-fit, so content-width is our last hope, and that is auto so that means we should be using the intrinsic image-width, determine width from there, so the e-g height becomes intrinsic image-height (and the block height). and fo:external-graphic src=... width=auto content-width=auto height=2.9cm content-height=scale-to-fit scaling=non-uniform / but here I'd expect the block height to be at most 2.9cm. That is currently not the case. This seems to be giving strange results... Those interested, try it out. On my side, it seems like the intrinsic image height is used to determine the block height (?) Not the behavior I would expect... Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Image in table not fitting full height?
scaling-method is not evaluated by FOP, so it can't be the problem.
Images are always embedded as is and scaled by the viewer/RIP. That
means that the scaling is always target-device-specific.
The gaps above and below of the images come from line-building, i.e.
from the line-height property among other factors. I was asked about the
same problem by the manufacturer of an FO editor. I still owe him a
reponse. :-( Anyway, I think we still have a bug in line-building. I'll
have to investigate a little further to come up with a test case. But I
think I found a work-around that works for now:
fo:block background-color=yellow font-size=0pt
fo:external-graphic content-height=40pt
src=url('http://www.apache.org/images/asf_logo_wide.gif')/
/fo:block
Setting font-size to 0pt does the trick because it doesn't create any
half-leading trait, or rather a 0mpt value.
In theory, the problem should be solved like this, I think:
fo:block background-color=yellow line-height=1.0
fo:external-graphic content-height=40pt
src=url('http://www.apache.org/images/asf_logo_wide.gif')
alignment-baseline=after-edge/
/fo:block
If I'm not mistaken, line-height=1.0 should in theory not lead to a
half-leading trait but that doesn't seem to happen right now. The
alignment-baseline is optional here as there are no characters in this
block that could have a descender because external-graphic is normally
aligned with the baseline AFAIK. But if there were additional
characters, this might be necessary depending on the expectations. Maybe
Manuel has some additional insight here. I'm not the line-building
specialist.
HTH
On 10.12.2005 22:20:23 Andreas L Delmelle wrote:
On Dec 10, 2005, at 13:52, Dirk Bromberg wrote:
Here is my fo sample. And a screenshot form the pdf.
I want the image in the xsl-region-before to scale the full
height of the cell (table) but there is 1mm border above and 2 mm
border below the image remaining. Are there default marigns
paddings or borders at cells block or tables?
Please tell me how to make the logo fits image to the full table
height.
The most likely cause seems to be scaling-method. If that property
set to auto (= initial value) then the formatter may choose the
method. I'm guessing all three tested formatters default to integer-
pixels, which could cause rounding in determining the number of
device pixels...
As a workaround, maybe you could try making the table-cell's
background-color black, which would at least create the desired
appearance.
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: fo:index
On Dec 11, 2005, at 13:17, gerhard oettl wrote: On Sun, Dec 11, 2005 at 10:54:48AM +0100, gerhard oettl wrote: [1] i think a lot of page-number-citation objects could do the trick, but if i can avoid that i would prefere. I forgot to mention, that my main problem is not to get the page-numbers but to supress duplicates. Ouch! Then it seems you're out of luck FTM, as there is absolutely no way to determine at XSLT stage what the value of the page-number- citation will be... Sorry. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fo:index
On Sun, Dec 11, 2005 at 05:35:36PM +0100, Andreas L Delmelle wrote: On Dec 11, 2005, at 13:17, gerhard oettl wrote: On Sun, Dec 11, 2005 at 10:54:48AM +0100, gerhard oettl wrote: [1] i think a lot of page-number-citation objects could do the trick, but if i can avoid that i would prefere. I forgot to mention, that my main problem is not to get the page-numbers but to supress duplicates. Ouch! Then it seems you're out of luck FTM, as there is absolutely no way to determine at XSLT stage what the value of the page-number- citation will be... I was afraid that this will be the answer. Nevertheless thank you for your example - maybe there are less duplicates than i expect. gerhard -- .''`. gerhard oettl on Debian/Gnu Linux : :' : `. `'` gpg key: 1024D/D59131AA 2002-06-18 `- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: group-by
On Dec 7, 2005, at 22:52, [EMAIL PROTECTED] wrote:
Hi,
I saw this question was still unanswered. This is most likely because
it is indeed slightly OT for this list. For XSLT-related questions,
you may want to check out the Mulberry XSLT list in the future.
I am confused about the group-by XSL functionality
xsl:for-each-group
select=xmlReportOutput/reportOutput/records/record
group-by=saxon:evaluate($sortColumn1)
xsl:sort select=saxon:evaluate($sortColumn1)
order={$sortColumn1Order}/
xsl:variable name=group1
select=current-grouping-key()/
xsl:call-template name=RenderByDesk
xsl:with-param name=tradeType
select=$group1/
/xsl:call-template
/xsl:for-each-group
However the values in $sortColumn1 has 4 different
possibilities
lets say A, B, C, D
and I need some logic that groups all As into one group and
everything
else into another group ( A = group1 -- B,C,D = group2 ) .
I haven't had much experience with XSLT 2.0 yet, but I suppose, since
the group-by attribute must be an expression, you could try something
like:
group-by=saxon:evaluate($sortColumn1)='A'
HTH!
Cheers,
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.90 alpha: problem with table borders and page breaks
On Thu, Dec 08, 2005 at 04:06:16PM +0100, Jeremias Maerki wrote: Problem fixed in Subversion: http://svn.apache.org/viewcvs?rev=355105view=rev :-) this fixes the descripted issue but has another unwanted side effect: if a cell that spannes more rows is broken between two pageges you get the following behaviour: +--+--+ | header col1 | header col2 | +--+--+ | rowspan=6 | row1 | | |--+ | | row2 | | |--+ | | row3 | +--+--+ --- pagebreak --- +--+--+ | header col1 | header col2 | +--+--+ | | row4 | +--+--+ | | row5 | +--+--+ | | row6 | +--+--+ the first page is ok but on the second the spanned cell has horizontal lines (borders) _within_ the spanned rowcount. gerhard -- .''`. gerhard oettl on Debian/Gnu Linux : :' : `. `'` gpg key: 1024D/D59131AA 2002-06-18 `- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Excel format
I think there isn´t any render to Excel actually :-( But I use a alternative way using JExcel. I use the XML file generated before FO traslation to generate very fast the xls file, is very easy if you have the xml data based in lines and columns. Salut De: Farid Adhami [mailto:[EMAIL PROTECTED] Enviado el: miércoles, 07 de diciembre de 2005 0:57Para: fop-users@xmlgraphics.apache.orgAsunto: Excel format Im trying to use FOP as report engine. But I have to provide excel format for the report. I didnt find any information showing that FOP provides Excel output or anyway that could be used for this purpose. Thanks for any help, in advance. Farid
