Re: Problem with svg
Thanks very much. it works!. unfortunately it has a small side-effect. the integrating of png in rtfs (with the following snippet) is no longer possible. for me it isn't necessary, but it would be a nive feature ;-) thanks very much regards, sascha fo:block text-align=center padding-after=15pt fo:external-graphic content-type=image/png src=image.png scaling=uniform inline-progression-dimension.optimum=auto inline-progression-dimension.maximum=505px block-progression-dimension.optimum=auto block-progression-dimension.maximum=710px/ /fo:block - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java IO Exception Error
Thanks. It was a problem with the style sheet On 12/9/05 5:36 PM, J.Pietschmann [EMAIL PROTECTED] wrote: Charles Murphy wrote: javax.xml.transform.TransformerException: Had IO Exception with stylesheet file: .\report_drivers\Includes.xsl The Java library had problems accessing the file Includes.xsl. Check whether you can open the file with some other tool (you seem to run Windows, try Notepad). The file might lack read permissions. Another possibility is that you have both an Includes.xsl and includes.xsl file in the same directory. This is not a FOP specific problem. You should ask again in a more general Java forum, preferably one where Java-on-Windows gurus hang out. J.Pietschmann - 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: Problem with svg
PNG support for RTF output is restored now in Subversion. Thanks for reporting that. On 13.12.2005 12:14:11 Sascha Iseli wrote: Thanks very much. it works!. unfortunately it has a small side-effect. the integrating of png in rtfs (with the following snippet) is no longer possible. for me it isn't necessary, but it would be a nive feature ;-) thanks very much regards, sascha fo:block text-align=center padding-after=15pt fo:external-graphic content-type=image/png src=image.png scaling=uniform inline-progression-dimension.optimum=auto inline-progression-dimension.maximum=505px block-progression-dimension.optimum=auto block-progression-dimension.maximum=710px/ /fo:block 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
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: ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=only margin-top=1in margin-left=1in margin-right=1in margin-bottom=1in fo:region-body region-name=only/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=only fo:flow flow-name=only fo:block fo:external-graphic src=tooWideGraphic.jpg content-height=auto content-width=468px height=auto width=auto/ /fo:block /fo:flow /fo:page-sequence /fo:root Here's the XML file I used to define the testing: ?xml version=1.0 encoding=UTF-8? test-values test name=content-width valueauto/value valuescale-to-fit/value value16.51cm/value value165.1mm/value value6.5in/value value468pt/value value39pc/value value468px/value value100%/value /test test name=content-height valueauto/value valuescale-to-fit/value value16.51cm/value value165.1mm/value value6.5in/value value468pt/value value39pc/value value468px/value value100%/value /test test name=height valueauto/value value16.51cm/value value165.1mm/value value6.5in/value value468pt/value value39pc/value value468px/value value100%/value /test test name=width valueauto/value value16.51cm/value value165.1mm/value value6.5in/value value468pt/value value39pc/value value468px/value value100%/value /test test name=image-type valuegif/value valuejpg/value /test test name=image-name valuetooNarrowGraphic/value valuetooWideGraphic/value /test /test-values (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). 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. Jay Bryant Bryant Communication Services (presently consulting at Synergistic Solution Technologies) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Shared hosting for FOP?
I have two hosted servers that I might be able to help you with. Send me an email at [EMAIL PROTECTED] and we can talk about it offline. Cheers, Curtis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
please fix bug 14962
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 qandaentry in a qandaset 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
