Re: Base 14 fonts
Hi, Base-14 Fonts The Adobe PDF Specification specifies a set of 14 fonts that must be available to every PDF reader: Helvetica (normal, bold, italic, bold italic), Times (normal, bold, italic, bold italic), Courier (normal, bold, italic, bold italic), Symbol and ZapfDingbats. http://www.cs.helsinki.fi/group/xmltools/formatters/fop/fop-0.20.5/build/site/fonts.html#Base-14+Fonts Venkat. Gregory Buchenberger wrote: Hi, Does anyone know of a free source where I might find the base 14 fonts? Thanks, Greg Buchenberger - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Base 14 fonts
Hi, This is from the latest FOP documentation... Base-14 Fonts The Adobe PostScript and PDF Specification specify a set of 14 fonts that must be available to every PostScript interpreter and PDF reader: Helvetica (normal, bold, italic, bold italic), Times (normal, bold, italic, bold italic), Courier (normal, bold, italic, bold italic), Symbol and ZapfDingbats. The following font family names are hard-coded into FOP for the Base-14 font set: Base-14 fontfont families Helvetica Helvetica, sans-serif, SansSerif Times Times, Times Roman, Times-Roman, serif, any Courier Courier, monospace, Monospaced Symbol Symbol ZapfDingbatsZapfDingbats Please note that recent versions of Adobe Acrobat Reader replace "Helvetica" with "Arial" and "Times" with "Times New Roman" internally. GhostScript replaces "Helvetica" with "Nimbus Sans L" and "Times" with "Nimbus Roman No9 L". Other document viewers may do similar font substitutions. If you need to make sure that there are no such substitutions, you need to specify an explicit font and embed it in the target document. Venkat. Gregory Buchenberger wrote: Hi, Does anyone know of a free source where I might find the base 14 fonts? Thanks, Greg Buchenberger - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: again strange keeps
Hi Georg, Georg Datterl wrote: > Hi Vincent, > > You explanations sounds quite good, but if I replace the keeps "5" with > "always", the whole block, images and everything, move to the next page. Is > that, because that's more "desireable"? That’s because you use keep-with-next.within-page instead of .within-column, and that has a side-effect on the table algorithm. In short: .within-column forbids any block-level break whatsoever, whereas .within-page only forbids page breaks. This is enough for the table algorithm to build a different sequence of elements, and skip the preferable break after the ‘TEST’ block. Replace your keep.within-page with keep.within-column and you get the expected output. > The present solution with the headre and the final, empty line on the next > page is in any case least desireable, because it looks ugly. Do you see a way > to force the images and two tables on the first page, the third table and > image on the second page? > > Regards, > > Georg Datterl HTH, Vincent PS: please, next time, could you try and simplify your FO document to use more ‘regular’ dimensions? For example, a padding of 1.5pt instead of 1.417pt, a space-after of 6pt instead of 5.669pt, etc. That would ease the debugging a lot (provided you can still reproduce your problem, of course). Thanks :-) > -- 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: Donnerstag, 3. Dezember 2009 13:24 > An: fop-users@xmlgraphics.apache.org > Betreff: Re: again strange keeps > > Hi Georg, > > Georg Datterl wrote: >> Hi everybody, hi Vincent, >> >> Attached fo file contains the already well known tables, now for A6 format. >> In this case, the right column contains three short tables and one image. >> Since that's too much for one page, fop inserts a break before the last line >> of the third table, overriding a keep-with-next.within-page="5". Now I would >> have expected the keep at the red block with the "TEST"-Text, since this >> block does not have any keeps, but obviously I'm missing something here. Can >> somebody help? > > Support for integer keeps is very limited at the moment. A break occurring > within an integer keep will simply be given maximum penalty in the hope that > breaks at better places (i.e., where keep has been left to > auto) will be privileged. All integer values result into the same break > penalty. In fact, the current implementation supports only 3 keep > values: auto, 'highly desirable', always. > > A break where keep is highly desirable may still be privileged over a break > where keep is auto if that leads to a better overall layout; for example, if > breaking at auto places would lead to half-empty pages whereas breaking at > undesirable places would give full pages. (This is not compliant with the > Recommendation, for that matter.) > > In the present case, however, there is something else that comes into > play: since the two images in the first column must be kept together, they > make a big unbreakable block. Therefore, the table algorithm will put as much > content from the second column as possible to match the height of the first > one (the heuristic being that full tables are more desirable). By doing that, > it will skip the acceptable breaks after the TEST blocks, and will end up > with the less acceptable ones inside the inner tables. > > >> 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 > > > Vincent - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
AW: again strange keeps
Hi Vincent, I'll try your suggestion on Monday. Thanks a lot. I do try to simplify my fos, but usually I end up with a simple fo which doesn't show the problem any longer. But I did not know this values make debugging harder. I'll keep it in mind for the next problem. Regards and have a nice weekend, 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: Freitag, 4. Dezember 2009 17:03 An: fop-users@xmlgraphics.apache.org Betreff: Re: again strange keeps Hi Georg, Georg Datterl wrote: > Hi Vincent, > > You explanations sounds quite good, but if I replace the keeps "5" with > "always", the whole block, images and everything, move to the next page. Is > that, because that's more "desireable"? That's because you use keep-with-next.within-page instead of .within-column, and that has a side-effect on the table algorithm. In short: .within-column forbids any block-level break whatsoever, whereas .within-page only forbids page breaks. This is enough for the table algorithm to build a different sequence of elements, and skip the preferable break after the 'TEST' block. Replace your keep.within-page with keep.within-column and you get the expected output. > The present solution with the headre and the final, empty line on the next > page is in any case least desireable, because it looks ugly. Do you see a way > to force the images and two tables on the first page, the third table and > image on the second page? > > Regards, > > Georg Datterl HTH, Vincent PS: please, next time, could you try and simplify your FO document to use more 'regular' dimensions? For example, a padding of 1.5pt instead of 1.417pt, a space-after of 6pt instead of 5.669pt, etc. That would ease the debugging a lot (provided you can still reproduce your problem, of course). Thanks :-) > -- 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: Donnerstag, 3. Dezember 2009 13:24 > An: fop-users@xmlgraphics.apache.org > Betreff: Re: again strange keeps > > Hi Georg, > > Georg Datterl wrote: >> Hi everybody, hi Vincent, >> >> Attached fo file contains the already well known tables, now for A6 format. >> In this case, the right column contains three short tables and one image. >> Since that's too much for one page, fop inserts a break before the last line >> of the third table, overriding a keep-with-next.within-page="5". Now I would >> have expected the keep at the red block with the "TEST"-Text, since this >> block does not have any keeps, but obviously I'm missing something here. Can >> somebody help? > > Support for integer keeps is very limited at the moment. A break > occurring within an integer keep will simply be given maximum penalty > in the hope that breaks at better places (i.e., where keep has been > left to > auto) will be privileged. All integer values result into the same > break penalty. In fact, the current implementation supports only 3 > keep > values: auto, 'highly desirable', always. > > A break where keep is highly desirable may still be privileged over a > break where keep is auto if that leads to a better overall layout; for > example, if breaking at auto places would lead to half-empty pages > whereas breaking at undesirable places would give full pages. (This is > not compliant with the Recommendation, for that matter.) > > In the present case, however, there is something else that comes into > play: since the two images in the first column must be kept together, they > make a big unbreakable block. Therefore, the table algorithm will put as much > content from the second column as possible to match the height of the first > one (the heuristic being that full tables are more desirable). By doing that, > it will skip the acceptable breaks after the TEST blocks, and will end up > with the less acceptable ones inside the inner tables. > > >> Regards, >> >> Georg Datterl >> >> -- Kontakt -- >>
Re: Base 14 fonts
Hi Gregory, Gregory Buchenberger wrote: > Hi, > > Does anyone know of a free source where I might find the base 14 fonts? You can get the fonts distributed with Ghostscript at the following address: http://sourceforge.net/projects/gs-fonts/ They are clones of the Base14 fonts contributed by URW++ and made available under the GPL license. > Thanks, > > Greg Buchenberger HTH, Vincent - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: [Xmlgraphics-fop Wiki] Update of "HowTo/XmlCommonsResolver" by JackBates
Hi Jack,
Thanks for this addition. I note that the page originally describes
how to use the catalog resolver for retrieving images. The -catalog
option specifically only works for the conversion from XML to
output. (In such a case FOP sets up the transformation from XML to FO
using XSLT, and in that setup the -catalog option adds a catalog
resolver.) Even with the -catalog option the catalog resolver is not
used for image retrieval. (Maybe it should, but I have not thought of
it.) Your addition should make this distinction clear. Therefore I
think that the section 'Command line option' should be at the end,
followed by the note about the W3C.
Regarding the catalog resolver in Java 6, I am not sure that it is
present in other Java installations than the one from Sun,
specifically in OpenJDK. Note that the class name is Sun's class
name. This should be checked.
Regards, Simon
On Thu, Dec 03, 2009 at 07:53:49PM -, Apache Wiki wrote:
> Dear Wiki user,
>
> You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki"
> for change notification.
>
> The "HowTo/XmlCommonsResolver" page has been changed by JackBates.
> http://wiki.apache.org/xmlgraphics-fop/HowTo/XmlCommonsResolver?action=diff&rev1=6&rev2=7
>
> --
>
> You can download it at: http://xml.apache.org/mirrors.cgi
>
> The main website is at: http://xml.apache.org/commons/components/resolver/
> +
> + XML Commons Resolver is
> [http://thread.gmane.org/gmane.text.xml.fop.user/29585 included in Java 6],
> so if you're running Java 6 or later, it's already installed. In Java 6 the
> catalog resolver class name is,
> com.sun.org.apache.xml.internal.resolver.tools.CatalogResolver
>
> = The Example =
>
> @@ -31, +33 @@
>
>
>* Run the ExampleFO2PDF!WithResolver class.
>
> + = Command line option =
> +
> + Simon Pepping [http://thread.gmane.org/gmane.text.xml.fop.user/29585 added
> a -catalog option] in
> [http://svn.apache.org/viewvc?view=revision&revision=825875 revision 825875].
> With this option you can render XML with the FOP command and use the catalog
> resolver:
> +
> + {{{ $ ./fop -catalog -xml icaatom.html -xsl icaatom.xsl icaatom.pdf}}}
> +
> = Notes =
>
> You will recognize that the FO file is specified through a "URN", too, not
> just the image referenced in the FO file. This is simply to make it easier
> for you to set up the demo. The FO file itself will be loaded directly from
> the Web.
>
> + Since the W3C started
> [http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic
> blocking abusive request patterns] for DTDs, it may be necessary to use local
> copies of these DTDs instead. A good way to do this is with the catalog
> resolver. Errors like the following may happen when you try using a DTD from
> the W3C's servers:
> +
> + {{{
> + java.io.IOException: Server returned HTTP response code: 503 for URL:
> http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
> + }}}
> +
>
> -
> To unsubscribe, e-mail: fop-commits-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: fop-commits-h...@xmlgraphics.apache.org
>
--
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: [Xmlgraphics-fop Wiki] Update of "HowTo/XmlCommonsResolver" by JackBates
Thank you Simon - I made these corrections
On Fri, 2009-12-04 at 19:52 +0100, Simon Pepping wrote:
> Hi Jack,
>
> Thanks for this addition. I note that the page originally describes
> how to use the catalog resolver for retrieving images. The -catalog
> option specifically only works for the conversion from XML to
> output. (In such a case FOP sets up the transformation from XML to FO
> using XSLT, and in that setup the -catalog option adds a catalog
> resolver.) Even with the -catalog option the catalog resolver is not
> used for image retrieval. (Maybe it should, but I have not thought of
> it.) Your addition should make this distinction clear. Therefore I
> think that the section 'Command line option' should be at the end,
> followed by the note about the W3C.
>
> Regarding the catalog resolver in Java 6, I am not sure that it is
> present in other Java installations than the one from Sun,
> specifically in OpenJDK. Note that the class name is Sun's class
> name. This should be checked.
>
> Regards, Simon
>
> On Thu, Dec 03, 2009 at 07:53:49PM -, Apache Wiki wrote:
> > Dear Wiki user,
> >
> > You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop
> > Wiki" for change notification.
> >
> > The "HowTo/XmlCommonsResolver" page has been changed by JackBates.
> > http://wiki.apache.org/xmlgraphics-fop/HowTo/XmlCommonsResolver?action=diff&rev1=6&rev2=7
> >
> > --
> >
> > You can download it at: http://xml.apache.org/mirrors.cgi
> >
> > The main website is at: http://xml.apache.org/commons/components/resolver/
> > +
> > + XML Commons Resolver is
> > [http://thread.gmane.org/gmane.text.xml.fop.user/29585 included in Java 6],
> > so if you're running Java 6 or later, it's already installed. In Java 6 the
> > catalog resolver class name is,
> > com.sun.org.apache.xml.internal.resolver.tools.CatalogResolver
> >
> > = The Example =
> >
> > @@ -31, +33 @@
> >
> >
> >* Run the ExampleFO2PDF!WithResolver class.
> >
> > + = Command line option =
> > +
> > + Simon Pepping [http://thread.gmane.org/gmane.text.xml.fop.user/29585
> > added a -catalog option] in
> > [http://svn.apache.org/viewvc?view=revision&revision=825875 revision
> > 825875]. With this option you can render XML with the FOP command and use
> > the catalog resolver:
> > +
> > + {{{ $ ./fop -catalog -xml icaatom.html -xsl icaatom.xsl icaatom.pdf}}}
> > +
> > = Notes =
> >
> > You will recognize that the FO file is specified through a "URN", too,
> > not just the image referenced in the FO file. This is simply to make it
> > easier for you to set up the demo. The FO file itself will be loaded
> > directly from the Web.
> >
> > + Since the W3C started
> > [http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic
> > blocking abusive request patterns] for DTDs, it may be necessary to use
> > local copies of these DTDs instead. A good way to do this is with the
> > catalog resolver. Errors like the following may happen when you try using a
> > DTD from the W3C's servers:
> > +
> > + {{{
> > + java.io.IOException: Server returned HTTP response code: 503 for URL:
> > http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
> > + }}}
> > +
> >
> > -
> > To unsubscribe, e-mail: fop-commits-unsubscr...@xmlgraphics.apache.org
> > For additional commands, e-mail: fop-commits-h...@xmlgraphics.apache.org
> >
>
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
