DO NOT REPLY [Bug 3430] - Running Head Missing Line at the first 3 pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3430. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3430 Running Head Missing Line at the first 3 pages [EMAIL PROTECTED] changed: What|Removed |Added Summary|Running Head Missing Line at|Running Head Missing Line at |the first 3 pages |the first 3 pages --- Additional Comments From [EMAIL PROTECTED] 2002-05-13 07:25 --- The test case renders as expected with 0.20.3, with the exception of the last (forced blank) page. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 3692] - Table header sometimes does not work.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3692. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3692 Table header sometimes does not work. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-05-13 07:58 --- The requested header is displayed with 0.20.3. There appears to be interesting IPD calculation problems with some nested tables later in the document, probably due to roundoff. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Font Metrics AWT
I'm using fop v0.20.3, on WINNT 4.0 SP6, java v1.3.1 (required for the project - 1.4 not possible at this time) Here are the results from command line awt rendering for java 1.3.1 and java 1.4 (looks better) cu Torsten (ThanX for replies) -Original Message- From: Ralph LaChance [mailto:[EMAIL PROTECTED]] Sent: Samstag, 11. Mai 2002 04:22 To: [EMAIL PROTECTED] Subject: RE: Font Metrics AWT Trying to place your results on a JLabel rings a bell but I can't recall why Could you try running the vanilla command-line fop -awt and see if you get better results ? something like java -cp paths to xalan.jar xerces.jar batik.jar /fop.jar org.apache.fop.apps.Fop -xsl xslfile -xml xmlfile -awt Also, please give you fop version , os ? , the usual stuff (hmmm, perhaps I'm showing my age in more ways than one; I cannot recall if the current maintenance branch still has a command-line invocation. Our production usage is based on fop 0.20.1) ' Best, -Ralph LaChance awt_java1.4.gif Description: GIF image awt_java1.3.1.gif Description: GIF image - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
AW: AW: Latest FOP schema
J. Pietschmann wrote: fo:block are Rectangular areas, perhaps indented and with border, padding and other individual traits, nested into a rectangular area. I understand setting traits, properties. How about page layout, setting inline and baseline postitions? Does it imply a unconditional CRLF? What does the input below look look like on the page? fo:block level_0_text fills to position A fo:block level_1_text positioned at A fills to position B /fo:block more level_0_text positioned at B /fo:block Hansuli Anderegg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 3824] - MIF option with tables
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3824. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3824 MIF option with tables --- Additional Comments From [EMAIL PROTECTED] 2002-05-13 08:14 --- The MIF renderer (in 0.20.3) mistakenly assumes there is a paragraph open when creating a table, which is wrong if the table is a direct child of a fo:flow or static content. A workaround is to enclose the table in a fo:block. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
new batik
Hi, Since a new beta of batik has been released I think we can go with this for the next release. I will put the new batik into cvs and update the code to work with it. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/lib batik.jar readme
keiron 02/05/13 02:48:49 Modified:lib batik.jar readme Log: updated to batik1.5 beta 2 Revision ChangesPath 1.8 +3724 -3128xml-fop/lib/batik.jar Binary file 1.9 +1 -1 xml-fop/lib/readme Index: readme === RCS file: /home/cvs/xml-fop/lib/readme,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- readme21 Mar 2002 10:07:43 - 1.8 +++ readme13 May 2002 09:48:48 - 1.9 @@ -7,7 +7,7 @@ the test scripts. see build.xml in root for more information batik.jar -cvs 21/03/2002 +version 1.5beta2 created from all-jar build target the svg library from Batik at xml.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Proper use of font encodings for native fonts
One reason for waiting was to see how it would work. There are some user issues that have popped up but nothing too serious. It would be good to know how people should deal with this situation. A new patch would certainly help. Christian might be able to say more about this. On Sun, 2002-05-12 at 18:35, Rainer Garus wrote: The patch in http://marc.theaimsgroup.com/?l=fop-devm=101242543132144w=2 is only inserted in the maintenance branch, not in the main branch. Is the patch not accepted for the main branch? Due to changes in the main branch, the patch does not work for the main branch in the moment without modifications. It is necessary to send a new patch? Rainer Garus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: AW: Latest FOP schema
Comments intermingled. -Original Message- From: J.U. Anderegg [mailto:[EMAIL PROTECTED]] Sent: May 13, 2002 5:15 AM To: [EMAIL PROTECTED] Subject: AW: AW: Latest FOP schema J. Pietschmann wrote: fo:block are Rectangular areas, perhaps indented and with border, padding and other individual traits, nested into a rectangular area. I understand setting traits, properties. How about page layout, setting inline and baseline postitions? Does it imply a unconditional CRLF? It's not that there is a CRLF, or anything like it, after a block, but rather that if it is succeeded by block-level siblings that they will be stacked in the block-progression-direction, so the effect will be the same. Can you be more specific with respect to the other questions? What does the input below look look like on the page? fo:block level_0_text fills to position A fo:block level_1_text positioned at A fills to position B /fo:block more level_0_text positioned at B /fo:block I think the predominant opinion is (assume all of this fits on one page) - a normal block area (generated by the outer block) that contains: one or more line areas for level_0_text fills to position A; then a block area with one or more line areas for level_1_text positioned at A fills to position B; finally more line areas for more level_0_text positioned at B. Note that if your example had been fo:block level_0_text fills to position Afo:block level_1_text positioned at A fills to position B /fo:blockmore level_0_text positioned at B /fo:block then it would still be the same. Regards, AHS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/svg PDFAElementBridge.java PDFImageElementBridge.java PDFTranscoder.java SVGElement.java SVGUserAgent.java
keiron 02/05/13 03:29:53
Modified:lib Tag: fop-0_20_2-maintain batik.jar readme
src/org/apache/fop/image/analyser Tag: fop-0_20_2-maintain
SVGReader.java
src/org/apache/fop/svg Tag: fop-0_20_2-maintain
PDFAElementBridge.java PDFImageElementBridge.java
PDFTranscoder.java SVGElement.java
SVGUserAgent.java
Log:
updated to batik1.5beta2 and improved the useragent usage
Revision ChangesPath
No revision
No revision
1.5.2.3 +7456 -6745xml-fop/lib/batik.jar
Binary file
1.4.2.2 +1 -1 xml-fop/lib/readme
Index: readme
===
RCS file: /home/cvs/xml-fop/lib/readme,v
retrieving revision 1.4.2.1
retrieving revision 1.4.2.2
diff -u -r1.4.2.1 -r1.4.2.2
--- readme10 Feb 2002 02:01:15 - 1.4.2.1
+++ readme13 May 2002 10:29:51 - 1.4.2.2
@@ -5,7 +5,7 @@
the test scripts. see build.xml in root for more information
batik.jar the svg library from Batik at xml.apache.org
-
+version 1.5 beta2
buildtools.jar Ant tasks required for building FOP. Rebuild with
build.sh -f buildtools.xml in the top level directory.
No revision
No revision
1.12.2.2 +3 -34 xml-fop/src/org/apache/fop/image/analyser/SVGReader.java
Index: SVGReader.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/image/analyser/SVGReader.java,v
retrieving revision 1.12.2.1
retrieving revision 1.12.2.2
diff -u -r1.12.2.1 -r1.12.2.2
--- SVGReader.java3 Dec 2001 07:40:17 - 1.12.2.1
+++ SVGReader.java13 May 2002 10:29:52 - 1.12.2.2
@@ -1,5 +1,5 @@
/*
- * $Id: SVGReader.java,v 1.12.2.1 2001/12/03 07:40:17 keiron Exp $
+ * $Id: SVGReader.java,v 1.12.2.2 2002/05/13 10:29:52 keiron Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
@@ -108,7 +108,7 @@
}
}
-protected class MUserAgent implements UserAgent {
+protected class MUserAgent extends UserAgentAdapter {
AffineTransform currentTransform = null;
/**
@@ -157,7 +157,7 @@
}
public String getMedia() {
-return ;
+return print;
}
public boolean isXMLParserValidating() {
@@ -179,21 +179,6 @@
return org.apache.fop.apps.Driver.getParserClassName();
}
-/**
- * Opens a link in a new component.
- * @param doc The current document.
- * @param uri The document URI.
- */
-public void openLink(SVGAElement elt) {
-}
-
-public Point getClientAreaLocationOnScreen() {
-return new Point(0, 0);
-}
-
-public void setSVGCursor(java.awt.Cursor cursor) {}
-
-
public AffineTransform getTransform() {
return currentTransform;
}
@@ -201,22 +186,6 @@
public Dimension2D getViewportSize() {
return new Dimension(100, 100);
}
-
-public EventDispatcher getEventDispatcher() {
-return null;
-}
-
-public boolean supportExtension(String str) {
-return false;
-}
-
-public boolean hasFeature(String str) {
-return false;
-}
-
-public void registerExtension(BridgeExtension be) {}
-
-public void handleElement(Element elt, Object data) {}
}
No revision
No revision
1.3.2.1 +1 -2 xml-fop/src/org/apache/fop/svg/PDFAElementBridge.java
Index: PDFAElementBridge.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/svg/PDFAElementBridge.java,v
retrieving revision 1.3
retrieving revision 1.3.2.1
diff -u -r1.3 -r1.3.2.1
--- PDFAElementBridge.java14 Aug 2001 14:50:30 - 1.3
+++ PDFAElementBridge.java13 May 2002 10:29:52 - 1.3.2.1
@@ -1,5 +1,5 @@
/*
- * $Id: PDFAElementBridge.java,v 1.3 2001/08/14 14:50:30 keiron Exp $
+ * $Id: PDFAElementBridge.java,v 1.3.2.1 2002/05/13 10:29:52 keiron Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
@@ -12,7 +12,6 @@
import org.apache.batik.bridge.*;
-import
Re: new batik
At 09:40 13/05/2002, Keiron Liddle wrote: Hi, Since a new beta of batik has been released I think we can go with this for the next release. You mean we'll go with the next *release* of Batik with the next release of FOP... We aren't shipping beta software with our release are we? Any chance of upping the version number of FOP to something like 0.91 because some people don't seem to like using software as low as 0.24 Alex Openweb Analysts Ltd, London: Software For Complex Websites http://www.OWAL.co.uk/ Free Consultancy for London Companies thinking of Open Source Software. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: new batik
On Mon, 2002-05-13 at 12:59, Alex McLintock wrote: At 09:40 13/05/2002, Keiron Liddle wrote: Hi, Since a new beta of batik has been released I think we can go with this for the next release. You mean we'll go with the next *release* of Batik with the next release of FOP... We aren't shipping beta software with our release are we? Considering how FOP uses batik and what has been recently developed in batik, the animations and scripting. I think this should be very stable for its use within FOP. The main issue is about the api and this is an improvement from the previous situation anyway. Alternatively we could wait an indefinite amount of time where the situation may still be the same. I am simply removing a barrier to a release. Any chance of upping the version number of FOP to something like 0.91 because some people don't seem to like using software as low as 0.24 I didn't know making software was as easy as setting a number. Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: new batik
Alex wrote: Any chance of upping the version number of FOP to something like 0.91 because some people don't seem to like using software as low as 0.24 At 12:45 13/05/2002, Keiron Liddle wrote: I didn't know making software was as easy as setting a number. I should have put a smiley in there but it is a serious point. Some people are not using Fop because of its low version number. You and I know that the version 1.0 will be the one which complies with the XSL:FO spec and we are a long way from that. FOP does not cope with the whole spec but it is quite satisfactory for many jobs. However there is a purely psychological problem with using software with such a low version number - it discourages some potential users. That is why I suggested skipping some version numbers but still keeping it below version 1.0 Ale Openweb Analysts Ltd, London: Software For Complex Websites http://www.OWAL.co.uk/ Free Consultancy for London Companies thinking of Open Source Software. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Version numbers (WAS:RE: new batik)
Believe me when I say that I am well aware of how important promotion is in a project, but I still don't think that we should inflate a version number just to attract new users. FOP has now had articles published about it more than once in XML Journal, which is a far greater sign to users of FOP's capabilities than a version number. If we really wanted to be more appealing from a marketing perspective, I'd suggest that we instead use a milestone release system for production releases and leave the version numbers under the covers so to speak. Although, in all honesty, I don't think we really need to do that. FOP's got enough good PR without us slinging version numbers about to get a little bit more. This does touch on a more important issue, though. Do we have a standard for our version numbers? I was thinking that, until 1.0, it'd be a good idea for each release to denote what percentage of the FO spec we feel we've covered. For example, 0.20 would be a release supporting a fifth of the FO spec features. Just a thought. -Original Message- From: Alex McLintock [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 8:18 AM To: [EMAIL PROTECTED] Subject: Re: new batik Alex wrote: Any chance of upping the version number of FOP to something like 0.91 because some people don't seem to like using software as low as 0.24 At 12:45 13/05/2002, Keiron Liddle wrote: I didn't know making software was as easy as setting a number. I should have put a smiley in there but it is a serious point. Some people are not using Fop because of its low version number. You and I know that the version 1.0 will be the one which complies with the XSL:FO spec and we are a long way from that. FOP does not cope with the whole spec but it is quite satisfactory for many jobs. However there is a purely psychological problem with using software with such a low version number - it discourages some potential users. That is why I suggested skipping some version numbers but still keeping it below version 1.0 Ale Openweb Analysts Ltd, London: Software For Complex Websites http://www.OWAL.co.uk/ Free Consultancy for London Companies thinking of Open Source Software. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Latest FOP schema
Arved Sandstrom Arved_37@ wrote: I think the predominant opinion is (assume all of this fits on one page) - a normal block area (generated by the outer block) that contains: one or more line areas for level_0_text fills to position A; then a block area with one or more line areas for level_1_text positioned at A fills to position B; finally more line areas for more level_0_text positioned at B. Note that if your example had been fo:block level_0_text fills to position Afo:block level_1_text positioned at A fills to position B /fo:blockmore level_0_text positioned at B /fo:block then it would still be the same. As a side note, assuming western language and script and hyphenation off, if the example had been fo:block level_0_text fills to position Afo:blocklevel_1_text positioned at A fills to position B /fo:blockmore level_0_text positioned at B /fo:block it is probably illegal, according to 4.7.2, Point 3. I suppose it would be illegal to have a line break within the word Alevel_1_text here. The problem here is, where do I get the rules whether a line break is permitted somewhere for a certain language and script? And how is this supposed to deal with out of context stuff like product numbers or artificial DB keys or programming language identifiers containing underlines and dashes, and with non-breaking spaces, odd symbols, and character abuse (uppercase greek omega instead of Ohm sign)? Again, I suppose the burden has to be put on the user who has to ensure everything is correct, including changing the current language for quotes, nested if necessary, and specifying a language for product numbers and programming language ids. Umm, something looking like ..., ISBN fo:inline language=x-isbn0-201-48345-9/fo:inline... and the fo:inline language=x-Javaorg.apache.fop.render.pdf.Fontfo:inline class implements the fo:inline language=x-Javaorg.apache.fop.layout.FontMetricfo:inline interface ... This would eleminate some keep-together stuff, I guess, but most probably requires a mechanism to teach the processor line breaking rules for user defined languages. DumbQuestions - Is the interpretation reasonable? (I don't ask about correctness...:-) - Can the redesigned FOP deal with the Alevel_1_text above, I mean will it raise an error or warning? - Can/should FOP deal with user supplied word/line breaking rules? /DumbQuestions Note that the same applies to the recently heavily discussed problem of a block level element inside an fo:inline, according to 4.7.3, in particular point 3. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
fo:external-graphic
Hello, I have to make a FOP customization for processing the fo:external-graphic statement.(Because the imges are stored in a strange way which i dont want to explain in details) What classes should i take a look at ? Whats the best entry point for that ? Thank you very much , Holger Prause - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: fo:external-graphic
I have to make a FOP customization for processing the fo:external-graphic statement.(Because the imges are stored in a strange way which i dont want to explain in details) Are you sure that this is really necessary? It would be interesting to know what exactly makes you believe you need to do that. URLs are a pretty flexible concept and you can always put in your own way of retrieving documents/images. What classes should i take a look at ? Whats the best entry point for that ? Basically this is everything in org.apache.fop.image, especially FopImageFactory. That's were the various formats are loaded. The analyzer subpackage is responsible for parsing some attributes like height and width from the image, before the whole image is loaded during rendering time. Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4233] - Table Split over 2 pages (Race condition???)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4233. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4233 Table Split over 2 pages (Race condition???) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-05-13 15:13 --- Don't use disable-output-escaping in transformations whose result is not serialized, as it happens if the transformation is called from the FOP driver. Consult a book or the XSL list archive for reasons. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9054] New: - PDF Tc Text operator BUG
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9054.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9054
PDF Tc Text operator BUG
Summary: PDF Tc Text operator BUG
Product: Fop
Version: 0.20.3
Platform: All
OS/Version: All
Status: NEW
Severity: Major
Priority: Other
Component: pdf renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I found that currently FOP outputs wrong pdf texts.
--- Sample fo ---
fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format;
fo:layout-master-set
fo:simple-page-master master-name=one
fo:region-body margin-top=50pt margin-bottom=50pt margin-left=100pt
margin-right=100pt/
/fo:simple-page-master
/fo:layout-master-set
fo:page-sequence master-reference=one
fo:flow flow-name=xsl-region-body
fo:blockA Block/fo:block
/fo:flow
/fo:page-sequence
/fo:root
--- End of sample fo
The above simple fo is converted to the below pdf texts.
BT
/F1 12 Tf
0 g
0.0 Tc
1 0 0 1 100.0 732.184 Tm [(A) 0.0 Tc
-278.0 (Block) ] TJ
ET
I think that Tc operator may not be included in TJ operator.
So, FOP should outputs below pdf texts.
BT
/F1 12 Tf
0 g
0.0 Tc
1 0 0 1 100.0 732.184 Tm [(A) -278.0 (Block) ] TJ
ET
Because of this problem, the TouchUp function of Adobe Acrobat4/5
could not work. The same problem is posted at fop-user ML.
Subject: TouchUp of Acrobat 4.0
From: Philippe Pithon [EMAIL PROTECTED]
Date: 2002-04-23 10:06:56
http://marc.theaimsgroup.com/?l=fop-userm=101955606713102w=2
I investigated from when this problem is awake. The cause is
the below commits for PDFRenderer for FOP-0.20.3 maintenance
release.
Subject: cvs commit: xml-fop/src/org/apache/fop/render/ps PSRenderer.java
PSStream.java
From: [EMAIL PROTECTED]
Date: 2001-12-02 22:17:30
http://marc.theaimsgroup.com/?l=fop-cvsm=100733236908296w=2
RCS file: /home/cvs/xml-fop/src/org/apache/fop/render/pdf/PDFRenderer.java,v
retrieving revision 1.91
retrieving revision 1.91.2.1
diff -u -r1.91 -r1.91.2.1
--- PDFRenderer.java 2001/09/26 12:00:42 1.91
+++ PDFRenderer.java 2001/12/02 22:17:30 1.91.2.1
@@ -548,6 +548,10 @@
addWordLines(area, rx, bl, size, areaColor);
+// Set letterSpacing
+float ls = area.getFontState().getLetterSpacing() /
this.currentFontSize;
+pdf.append(ls).append( Tc\n);
+
if (!textOpen || bl != prevWordY) {
closeText();
Probably, the above code comes from the support for
letter-spacing.
Subject: patch: added support for letter-spacing
From: Raymond Penners [EMAIL PROTECTED]
Date: 2001-11-29 14:59:18
http://marc.theaimsgroup.com/?l=fop-devm=100704585605951w=2
Regards.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
