Re: alignment-baseline and aligment-adjust properties
+1 for a) On 21.10.2005 02:28:42 Manuel Mall wrote: See the response at http://lists.w3.org/Archives/Public/xsl-editors/2005OctDec/0006.html. We have taken the opposite approach and added the property values to the property defintions. We could now: a) just remove them or b) leave the values in and issue a warning when used Given that FOP 0.20.5 doesn't support this at all and it is therefore unlikely we would be breaking anything for users moving from FOP 0.20.5 to FOP trunk if we go for option a) I would recommend to apply the KISS principle in this case and just remove them. Manuel Jeremias Maerki
Re: svn commit: r327144 - in /xmlgraphics/fop/trunk: build.xml src/java/org/apache/fop/Version.java src/java/org/apache/fop/apps/Fop.java
Had to scratch a little itch. :-) I hope nobody minds that. Two advantages: - we now only have one place (build.xml) where we set the version. - we hopefully get better feedback what version people are using when they report a problem. On 21.10.2005 12:17:38 jeremias wrote: Author: jeremias Date: Fri Oct 21 03:17:29 2005 New Revision: 327144 URL: http://svn.apache.org/viewcvs?rev=327144view=rev Log: FOP now retrieves the version information from the Manifest or from SVN information if the Manifest is not available. Added: xmlgraphics/fop/trunk/src/java/org/apache/fop/Version.java (with props) Modified: xmlgraphics/fop/trunk/build.xml xmlgraphics/fop/trunk/src/java/org/apache/fop/apps/Fop.java snip/ Jeremias Maerki
Re: alignment-baseline and aligment-adjust properties
On Oct 21, 2005, at 08:40, Jeremias Maerki wrote: On 21.10.2005 02:28:42 Manuel Mall wrote: We have taken the opposite approach and added the property values to the property defintions. We could now: a) just remove them or b) leave the values in and issue a warning when used +1 for a) Same here. If it was the intention of the editors to delete them, then it makes no sense at all to add them to the property definitions (like I myself suggested, IIRC). Cheers, Andreas
Re: alignment-baseline and aligment-adjust properties
On Oct 20, 2005, at 5:28 PM, Manuel Mall wrote: See the response at http://lists.w3.org/Archives/Public/xsl-editors/2005OctDec/0006.html. We have taken the opposite approach and added the property values to the property defintions. We could now: a) just remove them or b) leave the values in and issue a warning when used +1 a) Regards, Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Re: alignment-baseline and aligment-adjust properties
On Fri, Oct 21, 2005 at 08:28:42AM +0800, Manuel Mall wrote: See the response at http://lists.w3.org/Archives/Public/xsl-editors/2005OctDec/0006.html. We have taken the opposite approach and added the property values to the property defintions. We could now: a) just remove them or b) leave the values in and issue a warning when used Given that FOP 0.20.5 doesn't support this at all and it is therefore unlikely we would be breaking anything for users moving from FOP 0.20.5 to FOP trunk if we go for option a) I would recommend to apply the KISS principle in this case and just remove them. +1 for this proposal. Simon Manuel -- Simon Pepping home page: http://www.leverkruid.nl
Problem with Eastern european characters
Hello, I'm using FOP and I have the following problem : I transform a .FO to a PDF but this .FO contains Eastern european characters (ISO-8859-2/UTF-8 compatible), when looking at the resulting PDF I have a '#' for each eastern character. If I try another output different of PDF, the resulting document is correct. For remark : The PDF is correct if I use western european characters (like ISO-8859-1). This is as if the PDF font was ignoring my eastern characters. But I feel the problem is in the output way, because eastern european characters may require two encoding bytes. When using the (org.apache.fop.apps) Driver class, I have noticed that the output must be an OutputStream, so this is not character compatible but byte only compatible, it seems unicode cannot be processed correctly ? How an I process such characters ? Thank you in advance, Best regards, A.Brillant
Re: Problem with Eastern european characters
JAPISoft wrote: I transform a .FO to a PDF but this .FO contains Eastern european characters (ISO-8859-2/UTF-8 compatible), when looking at the resulting PDF I have a '#' for each eastern character. [...] This is as if the PDF font was ignoring my eastern characters. But I feel the problem is in the output way, because eastern european characters may require two encoding bytes. Your feeling isn't quite correct. Check the FAQ: http://xmlgraphics.apache.org/fop/faq.html#pdf-characters When using the (org.apache.fop.apps) Driver class, I have noticed that the output must be an OutputStream, so this is not character compatible but byte only compatible, it seems unicode cannot be processed correctly ? PDF isn't text, it is a binary format. For details, check the PDF spec. J.Pietschmann
