Re: XSL url path
On Tue, Oct 27, 2009 at 09:16:59PM -0700, fopinaus wrote: > > Hi there, > > Could you please tell me is it possible to use a url rather than a file for > the xslt in the command line? > > eg > > "C:\Program Files\fop-0.95\fop.bat" -xml "F:\test\testxml.xml" -xsl > "http://blah/testStylesheet.xsl"; -pdf "F:\test\test.pdf" > > If I just pass in the pass in the url as per the line above it gets prefixed > with c:\\ > Error: xsl file c:\\http:\blah\testStylesheet.xsl not found. Apparently it is not possible, as you yourself proved. It seems like FOP does not expect a URI, and considers the path as a relative path. This could definitively be improved. Simon -- Simon Pepping home page: http://www.leverkruid.eu - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: confusing tables again
Hi Georg, Georg Datterl wrote: > Hi Vincent, > >> To avoid that issue, remove the border on the outer block. > > I wish I could. But the border is necessary. > >> Alternatively, set its conditionality to retain. Be careful though: the >> conditionality can be set only on the relative property (border-after- >> width), not the absolute one (border-bottom-width): >>>border-after-width.conditionality="retain"... > > That would not give me a border on each page, would it? Yes, that would. It’s so tiny, nobody would see it, would it? :-) > Or is there a way to creatively use colapsing borders? That’s an idea. You could define an invisible (same colour as background), retained bottom border on the outer table, overridden by a hidden bottom border on an empty table footer, with table-omit-footer-at-break="true". At the page break, the footer wouldn’t be there, so the table border would win and account for the block’s discarded border. After the page break, the footer would nullify the border and you would get the normal border from the block. See attached FO file for an illustration. HTH, Vincent > Regards, > > Georg Datterl > > -- Kontakt -- > > Georg Datterl > > Geneon media solutions gmbh > Gutenstetter Straße 8a > 90449 Nürnberg > > HRB Nürnberg: 17193 > Geschäftsführer: Yong-Harry Steiert > > Tel.: 0911/36 78 88 - 26 > Fax: 0911/36 78 88 - 20 > > www.geneon.de > > Weitere Mitglieder der Willmy MediaGroup: > > IRS Integrated Realization Services GmbH:www.irs-nbg.de > Willmy PrintMedia GmbH:www.willmy.de > Willmy Consult & Content GmbH: www.willmycc.de > -Ursprüngliche Nachricht- > Von: Vincent Hennebert [mailto:vhenneb...@gmail.com] > Gesendet: Dienstag, 27. Oktober 2009 16:45 > An: fop-users@xmlgraphics.apache.org > Betreff: Re: confusing tables again > > Hi Georg, > > Georg Datterl wrote: >> Hi Vincent, >> >> I tried with the lates update, same result. See the two pdfs. Also attached >> find the images. I assumed they would be unnecessary, since I explicitely >> state content-height. > > Indeed; the problem was actually the font. Not having Arial FOP defaulted to > Times, which has different metrics and was then giving a different result. > After having replaced it with sans-serif I managed to reproduce your issue... > > ... And FOP's behaviour is actually perfectly fine. You defined a bottom > border of 0.4pt on the block surrounding the big table. That little border is > just enough to make the whole block not fit on the page, hence the page break > you get on the first version. Without that border the table would fit on one > page. > > In the second version with the additional block, the table itself becomes > bigger than the page, so that block must be deferred to the next page. The > width of the border defined on the outer block is conditional, so it must not > appear at the bottom of the first page. And since without that border the > inner table fits on the first page, FOP puts it there. > > To avoid that issue, remove the border on the outer block. > Alternatively, set its conditionality to retain. Be careful though: the > conditionality can be set only on the relative property (border-after-width), > not the absolute one (border-bottom-width): > border-after-width.conditionality="retain"... > > >> The footer image is unnecessary I guess, since it can't be included >> anyway (without Jeremias' extension). >> >> Regards, >> >> Georg Datterl > > HTH, > Vincent > > >> -- Kontakt -- >> >> Georg Datterl >> >> Geneon media solutions gmbh >> Gutenstetter Straße 8a >> 90449 Nürnberg >> >> HRB Nürnberg: 17193 >> Geschäftsführer: Yong-Harry Steiert >> >> Tel.: 0911/36 78 88 - 26 >> Fax: 0911/36 78 88 - 20 >> >> www.geneon.de >> >> Weitere Mitglieder der Willmy MediaGroup: >> >> IRS Integrated Realization Services GmbH:www.irs-nbg.de >> Willmy PrintMedia GmbH:www.willmy.de >> Willmy Consult & Content GmbH: www.willmycc.de >> -Ursprüngliche Nachricht- >> Von: Vincent Hennebert [mailto:vhenneb...@gmail.com] >> Gesendet: Montag, 26. Oktober 2009 11:30 >> An: fop-users@xmlgraphics.apache.org >> Betreff: Re: confusing tables again >> >> Hi Georg, >> >> Which version of FOP are you using? With the latest Trunk both files are >> rendered the exact same way. The referred images aren't available though. >> Can you try again with the latest Trunk, or send the images? >> >> Thanks, >> Vincent >> >> >> Georg Datterl wrote: >>> Hi everybody, >>> >>> It's me again and I'm still finding strange behaviours in regard to page >>> breaks. I know the new layouting is just somewhere around the corner, but >>> maybe you can find a workaround again. For those who came in late, here's >>> what I do: >>> >>> I have a table with images in one column and a table in the second column. >>> If the table breaks to
AW: confusing tables again
Hi Vincent, > To avoid that issue, remove the border on the outer block. I wish I could. But the border is necessary. > Alternatively, set its conditionality to retain. Be careful though: the > conditionality can be set only on the relative property (border-after- > width), not the absolute one (border-bottom-width): >border-after-width.conditionality="retain"... That would not give me a border on each page, would it? Or is there a way to creatively use colapsing borders? Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH:www.irs-nbg.de Willmy PrintMedia GmbH:www.willmy.de Willmy Consult & Content GmbH: www.willmycc.de -Ursprüngliche Nachricht- Von: Vincent Hennebert [mailto:vhenneb...@gmail.com] Gesendet: Dienstag, 27. Oktober 2009 16:45 An: fop-users@xmlgraphics.apache.org Betreff: Re: confusing tables again Hi Georg, Georg Datterl wrote: > Hi Vincent, > > I tried with the lates update, same result. See the two pdfs. Also attached > find the images. I assumed they would be unnecessary, since I explicitely > state content-height. Indeed; the problem was actually the font. Not having Arial FOP defaulted to Times, which has different metrics and was then giving a different result. After having replaced it with sans-serif I managed to reproduce your issue... ... And FOP's behaviour is actually perfectly fine. You defined a bottom border of 0.4pt on the block surrounding the big table. That little border is just enough to make the whole block not fit on the page, hence the page break you get on the first version. Without that border the table would fit on one page. In the second version with the additional block, the table itself becomes bigger than the page, so that block must be deferred to the next page. The width of the border defined on the outer block is conditional, so it must not appear at the bottom of the first page. And since without that border the inner table fits on the first page, FOP puts it there. To avoid that issue, remove the border on the outer block. Alternatively, set its conditionality to retain. Be careful though: the conditionality can be set only on the relative property (border-after-width), not the absolute one (border-bottom-width): The footer image is unnecessary I guess, since it can't be included > anyway (without Jeremias' extension). > > Regards, > > Georg Datterl HTH, Vincent > -- Kontakt -- > > Georg Datterl > > Geneon media solutions gmbh > Gutenstetter Straße 8a > 90449 Nürnberg > > HRB Nürnberg: 17193 > Geschäftsführer: Yong-Harry Steiert > > Tel.: 0911/36 78 88 - 26 > Fax: 0911/36 78 88 - 20 > > www.geneon.de > > Weitere Mitglieder der Willmy MediaGroup: > > IRS Integrated Realization Services GmbH:www.irs-nbg.de > Willmy PrintMedia GmbH:www.willmy.de > Willmy Consult & Content GmbH: www.willmycc.de > -Ursprüngliche Nachricht- > Von: Vincent Hennebert [mailto:vhenneb...@gmail.com] > Gesendet: Montag, 26. Oktober 2009 11:30 > An: fop-users@xmlgraphics.apache.org > Betreff: Re: confusing tables again > > Hi Georg, > > Which version of FOP are you using? With the latest Trunk both files are > rendered the exact same way. The referred images aren't available though. Can > you try again with the latest Trunk, or send the images? > > Thanks, > Vincent > > > Georg Datterl wrote: >> Hi everybody, >> >> It's me again and I'm still finding strange behaviours in regard to page >> breaks. I know the new layouting is just somewhere around the corner, but >> maybe you can find a workaround again. For those who came in late, here's >> what I do: >> >> I have a table with images in one column and a table in the second column. >> If the table breaks to a new page, on this page I need a copy of the images >> from the first page. So I generate the table with only the first image. Then >> I parse the area tree and find out, how many pages the table spans and how >> much space is left in the image column of the first page. Then I grab the >> image column, add an empty block spanning the remainder of the page, add the >> image (which is then displayed on the next page, of course), add another >> empty block and repeat for each page. >> >> withoutBlock.fo contains such a table. As you can see, the right table >> breaks to the second page and three rows are displayed there. On the first >> page you can already see a pink block below the image, this would be added >> after parsing the area tree. >> >> The second file, withBlock.fo contains a second pink block, which according >> to the data gained f
RE: Japanese characters in pdf & Encryption
Hi Pdf encryption for japanese characters are sucessfully coming in FOP Trunk. Thanks, Bharathram K -- View this message in context: http://www.nabble.com/Japanese-characters-in-pdf---Encryption-tp25988960p26090271.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
