Re: [POLL] Your experience with FOP 0.90alpha1 so far???
Ah, now I get it, thanks. It's actually so that 0.20.5 is at fault here. :-) Just sum up the line-height for each line in the b-c. You get 146pt which is about 2.02in which is 5.13cm. You specified 4.7cm as the height for the b-c. 0.20.5 wasn't so systematically tested as the new code is. Even if I look directly at the area tree that 0.90 generates, the result is correct. On 15.12.2005 23:47:31 Roland Neilands wrote: > Jeremias, > > Try the large block in 20.5 - it fits with no overflow. There seems to > be extra space between lines in .90 > > Cheers, > Roland > > Jeremias Maerki wrote: > > >On 12.12.2005 07:19:31 Roland Neilands wrote: > > > > > > > 5. There seems to be extra space inserted between lines now. This breaks > existing stylesheets static-content layout - is there some default > attribute I can turn off for this? (space-before, padding?) > > > > > >>>Can you please supply an example? > >>> > >>> > >>> > >>> > >>> > >>Yes: > >>It seems this is no longer respected as a blank line: > >> > >> > >> > > > >Manuel Mall just told me he's going to look into this. > > > > > > > >>This block-container overruns it's height by a full centimeter: > >> > >> > > > >Yes, I can see it overflows the available area. What exactly is the > >problem here? The current FOP Trunk (dev version) will notify you about > >the overflow in the log. The overflow property will now also clip the > >overflowing content is "hidden" is used. > > > > > > > >>- <#> >>top="*0cm*" width="*16cm*" height="*4.7cm*"> > >> >>font-family="*serif*" line-height="*26pt*" text-align="*start*">Pulse > >>Mining Systems Pty Ltd > >> >>font-family="*serif*" line-height="*20pt*" text-align="*start*">as > >>Managers and Agents for the Pulse Joint Venture > >> >>font-weight="*bold*" font-family="*serif*" line-height="*16pt*" > >>text-align="*start*">123456 4900 49336732 > >> >>font-weight="*bold*" font-family="*serif*" line-height="*12pt*" > >>text-align="*start*">18 Day Street > >> >>font-weight="*bold*" font-family="*serif*" line-height="*12pt*" > >>text-align="*start*">East Maitland NSW 2323 > >> >>font-weight="*bold*" font-family="*serif*" line-height="*12pt*" > >>text-align="*start*">Line 3 > >> >>font-weight="*bold*" font-family="*serif*" line-height="*12pt*" > >>text-align="*start*">Line 4 > >> >>font-weight="*bold*" font-family="*serif*" line-height="*12pt*" > >>text-align="*start*">Line 5 > >>- <#> >>font-family="*serif*" line-height="*12pt*" text-align="*start*"> > >> >>external-destination="*mailto:[EMAIL PROTECTED]" > >>color="*blue*">[EMAIL PROTECTED] > >> > >>- <#> >>font-family="*serif*" line-height="*12pt*" text-align="*start*"> > >> http://www.pulsemining.com.au*"; > >>color="*blue*">http://www.pulsemining.com.au > >> > >> > >> > >> > > > > > > > > > >Jeremias Maerki > > > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Type 1 Font Embedding
You don't need to embed Times-Roman because that font is covered by the Base-14 font package that is perscribed by the PDF standard. The fonts "Times", "Helvetica", "Courier", "ZapfDingbats" and "Symbol" can always be considered present in PDF and PostScript. Of course, "Times-Roman" may not have the same name as "Times" but "Times-Roman" is mapped to "Times" inside FOP for Compatibility with PassiveTex. So, just remove the font entries for Times-* and you'll be fine. On 16.12.2005 03:56:28 Paul wrote: > I fought many a dragon with fop and won. This time I've reaced the end > of my rope. :) > > I've created a book using docbook and wish to upload it for print to lulu.com. > > The problem is that they require the fonts to embeded. Fine, my > truetype fonts are embeded but there is a pesky "Times-Roman" type 1 > font that won't seem to get in there. > > I have the type 1 font, and added this to my userconfig: > > > metrics-file="/home/snafu/cvsroot/books/resource/fonts/core/TIR_.xml" > kerning="yes" > > embed-file="/home/snafu/cvsroot/books/resource/fonts/core/TIR_.PFB"> > weight="normal"/> > > metrics-file="/home/snafu/cvsroot/books/resource/fonts/core/TII_.xml" > kerning="yes" > > embed-file="/home/snafu/cvsroot/books/resource/fonts/core/TII_.PFB"> > weight="normal"/> > > metrics-file="/home/snafu/cvsroot/books/resource/fonts/core/TIB_.xml" > kerning="yes" > > embed-file="/home/snafu/cvsroot/books/resource/fonts/core/TIB_.PFB"> > weight="normal"/> > > > The pesky little bugger won't embed. > > Does anyone have a suggestion as to how I can either remove the > requirement for the type 1 font, or embed it so that the document may > be published? > > Thank you, > Paul Slinski Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Type 1 Font Embedding
I fought many a dragon with fop and won. This time I've reaced the end of my rope. :) I've created a book using docbook and wish to upload it for print to lulu.com. The problem is that they require the fonts to embeded. Fine, my truetype fonts are embeded but there is a pesky "Times-Roman" type 1 font that won't seem to get in there. I have the type 1 font, and added this to my userconfig: The pesky little bugger won't embed. Does anyone have a suggestion as to how I can either remove the requirement for the type 1 font, or embed it so that the document may be published? Thank you, Paul Slinski -- "It is hard enough to remember my opinions, without also remembering my reasons for them!" -- Friedrich Nietzsche - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Your experience with FOP 0.90alpha1 so far???
Jeremias, Try the large block in 20.5 - it fits with no overflow. There seems to be extra space between lines in .90 Cheers, Roland Jeremias Maerki wrote: On 12.12.2005 07:19:31 Roland Neilands wrote: 5. There seems to be extra space inserted between lines now. This breaks existing stylesheets static-content layout - is there some default attribute I can turn off for this? (space-before, padding?) Can you please supply an example? Yes: It seems this is no longer respected as a blank line: Manuel Mall just told me he's going to look into this. This block-container overruns it's height by a full centimeter: Yes, I can see it overflows the available area. What exactly is the problem here? The current FOP Trunk (dev version) will notify you about the overflow in the log. The overflow property will now also clip the overflowing content is "hidden" is used. - <#> top="*0cm*" width="*16cm*" height="*4.7cm*"> font-family="*serif*" line-height="*26pt*" text-align="*start*">Pulse Mining Systems Pty Ltd font-family="*serif*" line-height="*20pt*" text-align="*start*">as Managers and Agents for the Pulse Joint Venture font-weight="*bold*" font-family="*serif*" line-height="*16pt*" text-align="*start*">123456 4900 49336732 font-weight="*bold*" font-family="*serif*" line-height="*12pt*" text-align="*start*">18 Day Street font-weight="*bold*" font-family="*serif*" line-height="*12pt*" text-align="*start*">East Maitland NSW 2323 font-weight="*bold*" font-family="*serif*" line-height="*12pt*" text-align="*start*">Line 3 font-weight="*bold*" font-family="*serif*" line-height="*12pt*" text-align="*start*">Line 4 font-weight="*bold*" font-family="*serif*" line-height="*12pt*" text-align="*start*">Line 5 - <#> font-family="*serif*" line-height="*12pt*" text-align="*start*"> external-destination="*mailto:[EMAIL PROTECTED]" color="*blue*">[EMAIL PROTECTED] - <#> font-family="*serif*" line-height="*12pt*" text-align="*start*"> http://www.pulsemining.com.au*"; color="*blue*">http://www.pulsemining.com.au Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: please fix bug 14962
Hi Jeremias, Thank you very much-- I tried with FOP 0.90alpha1 and it seems to be fixed! Great work :-) Jason Jeremias Maerki wrote: Jason, please retest your documents with FOP 0.90alpha1. I've just run the test cases attached to bug 14962 and the bug does not occur. On 14.12.2005 00:23:55 Jason Novotny wrote: Hi, I'm glad to see that after 2 years of a release, work is going on redesigning FOP-- I always thought it had a lot of promise as a project but fell short. I just want to express my interest in having bug 14962 duplicate ID's fixed as soon as possible. Currently adding a new in a in docbook will lead to this kind of error: [java] org.apache.fop.apps.FOPException: file:/home/gridsphere/WWW/cvs.gridsphere.org/software/gridsphe re-docs/docs/docbook/FAQ/html/FAQ.fop:9:178 The id "N1000F" already exists in this document [java] at org.apache.fop.datatypes.IDReferences.createID(IDReferences.java:119) [java] at org.apache.fop.fo.flow.ListItem.layout(ListItem.java:133) It's incredibly frustrating since it means the output FOP file needs to be hand hacked in order to generate HTML or a PDF. This also means any kind of FAQ with docbook isn't very easy currently. Thanks, Jason Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Your experience with FOP 0.90alpha1 so far???
On 12.12.2005 07:19:31 Roland Neilands wrote: > >>5. There seems to be extra space inserted between lines now. This breaks > >>existing stylesheets static-content layout - is there some default > >>attribute I can turn off for this? (space-before, padding?) > >> > >> > > > >Can you please supply an example? > > > > > > > Yes: > It seems this is no longer respected as a blank line: > Manuel Mall just told me he's going to look into this. > This block-container overruns it's height by a full centimeter: Yes, I can see it overflows the available area. What exactly is the problem here? The current FOP Trunk (dev version) will notify you about the overflow in the log. The overflow property will now also clip the overflowing content is "hidden" is used. > - <#> top="*0cm*" width="*16cm*" height="*4.7cm*"> >font-family="*serif*" line-height="*26pt*" text-align="*start*">Pulse > Mining Systems Pty Ltd >font-family="*serif*" line-height="*20pt*" text-align="*start*">as > Managers and Agents for the Pulse Joint Venture >font-weight="*bold*" font-family="*serif*" line-height="*16pt*" > text-align="*start*">123456 4900 49336732 >font-weight="*bold*" font-family="*serif*" line-height="*12pt*" > text-align="*start*">18 Day Street >font-weight="*bold*" font-family="*serif*" line-height="*12pt*" > text-align="*start*">East Maitland NSW 2323 >font-weight="*bold*" font-family="*serif*" line-height="*12pt*" > text-align="*start*">Line 3 >font-weight="*bold*" font-family="*serif*" line-height="*12pt*" > text-align="*start*">Line 4 >font-weight="*bold*" font-family="*serif*" line-height="*12pt*" > text-align="*start*">Line 5 > - <#> font-family="*serif*" line-height="*12pt*" text-align="*start*"> >external-destination="*mailto:[EMAIL PROTECTED]" > color="*blue*">[EMAIL PROTECTED] > > - <#> font-family="*serif*" line-height="*12pt*" text-align="*start*"> > http://www.pulsemining.com.au*"; > color="*blue*">http://www.pulsemining.com.au > > Jeremias Maerki - 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
Thanks, Gerhard! I've just fixed this problem: http://svn.apache.org/viewcvs?rev=357008&view=rev On 11.12.2005 21:17:37 gerhard oettl wrote: > On Thu, Dec 08, 2005 at 04:06:16PM +0100, Jeremias Maerki wrote: > >Problem fixed in Subversion: > >http://svn.apache.org/viewcvs?rev=355105&view=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. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.90alpha1: content-width="scale-to-fit" creates damaged PDF
(some comments inline...) On 13.12.2005 22:02:52 JBryant wrote: > Hi, Jeremias, > > > 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. > > Well, I wrote some XSLT code that produced 124 test files. Here's a > typical file: > > > http://www.w3.org/1999/XSL/Format";> > >margin-top="1in" margin-left="1in" > margin-right="1in" margin-bottom="1in"> > > > > > > >src="tooWideGraphic.jpg" > content-height="auto" > content-width="468px" > height="auto" width="auto"/> > > > > > > Here's the XML file I used to define the testing: > > > > > auto > scale-to-fit > 16.51cm > 165.1mm > 6.5in > 468pt > 39pc > 468px > 100% > > > auto > scale-to-fit > 16.51cm > 165.1mm > 6.5in > 468pt > 39pc > 468px > 100% > > > auto > 16.51cm > 165.1mm > 6.5in > 468pt > 39pc > 468px > 100% > > > auto > 16.51cm > 165.1mm > 6.5in > 468pt > 39pc > 468px > 100% > > > gif > jpg > > > tooNarrowGraphic > tooWideGraphic > > > > (tooNarrowGraphic and tooWideGraphic are just simple images that are, > respectively, narrower or wider than the content area.) > > I wound up with 124 files rather than 20736 files because I blocked any > test that had more than one value that wasn't "auto". I could generate the > other files, but 124 is about my limit for visually checking PDF files to > see if I got the proper output. > > The good news is that I got the output I expected in all cases (though I > had to check the spec pretty carefully to be sure of that in some cases). From an implementor's point of view, blocking files with more than one non-auto value may not be ideal because sometimes combination with more restrictions uncover problems. On the other side, the various widths you used are rather testing the property subsystem than the image layout code. Also, it's not necessary to test different image formats. The code is the same. The only thing here is to make sure that the image loaders are reporting the image's intrinsic size correctly. I'd rather go after things like a width bigger and smaller than the available space or than the image size, respectively. > I figure I'll skip checking them all into your testing system, as it would > be massive overkill, but I thought you might want to know the results of > my testing. If you do want them (or some subset of them), let me know. > > Also, if you'd like me to programatically generate test files for other > elements or properties, let me know. It's not hard to do. > > > Concerning your suggestion of a "scale-down-to-fit" I'd say that > > this is not necessary provided I've understood your requirement. > > I can certainly get by without it, but it seems like a nice convenience > feature. It's in the 1.1 spec, so maybe I'll get to use it someday. I didn't know it was in the 1.1 spec. That changes the situation, of course. I was under the impression that the option is not necessary but I guess from a user's point of view this is easier than doing strange property combinations like I suggested. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
