cvs commit: xml-fop/src/org/apache/fop/fo FOText.java
pietsch 2003/03/02 05:04:16
Modified:src/org/apache/fop/fo Tag: fop-0_20_2-maintain FOText.java
Log:
Fixed destructive data mangling while preparing text for small-caps
font variation. The fix is simplisitc and can cause small caps
text to be expensive in terms of memory consumption and processing
time.
PR: 1171
Revision ChangesPath
No revision
No revision
1.24.2.8 +6 -3 xml-fop/src/org/apache/fop/fo/FOText.java
Index: FOText.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/FOText.java,v
retrieving revision 1.24.2.7
retrieving revision 1.24.2.8
diff -u -r1.24.2.7 -r1.24.2.8
--- FOText.java 25 Feb 2003 12:56:54 - 1.24.2.7
+++ FOText.java 2 Mar 2003 13:04:15 - 1.24.2.8
@@ -209,6 +209,7 @@
// parse text for upper/lower case and call addRealText
char c;
+char newdata[] = new char[end];
boolean isLowerCase;
int caseStart;
FontState fontStateToUse;
@@ -221,7 +222,9 @@
== (java.lang.Character.isLetter(c)
java.lang.Character.isLowerCase(c))) {
if (isLowerCase) {
-data[i] = java.lang.Character.toUpperCase(c);
+newdata[i] = java.lang.Character.toUpperCase(c);
+} else {
+newdata[i] = c;
}
i++;
if (i == end)
@@ -235,7 +238,7 @@
}
int index = addRealText(ba, fontStateToUse, red, green, blue,
wrapOption, ls, whiteSpaceCollapse,
-data, caseStart, i, textState,
+newdata, caseStart, i, textState,
vAlign);
if (index != -1) {
return index;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop CHANGES
pietsch 2003/03/02 05:06:23 Modified:.Tag: fop-0_20_2-maintain CHANGES Log: Addend CHANGES log entry for small caps fix. Revision ChangesPath No revision No revision 1.10.2.51 +2 -0 xml-fop/CHANGES Index: CHANGES === RCS file: /home/cvs/xml-fop/CHANGES,v retrieving revision 1.10.2.50 retrieving revision 1.10.2.51 diff -u -r1.10.2.50 -r1.10.2.51 --- CHANGES 17 Feb 2003 00:31:58 - 1.10.2.50 +++ CHANGES 2 Mar 2003 13:06:23 - 1.10.2.51 @@ -1,5 +1,7 @@ == Done since 0.20.4 release +- Fixed repeatedly laid out small caps text (for example in static + content or due ot keeps). (J.Pietschmann) - Fixed marker handling thouroughly. All retrieving boundaries and retrieve-position first-starting-within-page and last-starting-within-page should work now, as well as multiline/multiblock marker contents. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 1171] - small-caps in static content becomes all-caps
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=1171. 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=1171 small-caps in static content becomes all-caps [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-03-02 13:08 --- Fixed for 0.20.5rc3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/layout BlockArea.java
pietsch 2003/03/02 05:47:44
Modified:src/org/apache/fop/fo/flow Tag: fop-0_20_2-maintain
Block.java
src/org/apache/fop/layout Tag: fop-0_20_2-maintain
BlockArea.java
Log:
Set currentLine to null after adding it in BlockArea.
Some cosmetical rearrangements.
PR: 17472 and several postings
Revision ChangesPath
No revision
No revision
1.41.2.16 +16 -41xml-fop/src/org/apache/fop/fo/flow/Block.java
Index: Block.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Block.java,v
retrieving revision 1.41.2.15
retrieving revision 1.41.2.16
diff -u -r1.41.2.15 -r1.41.2.16
--- Block.java25 Feb 2003 12:57:00 - 1.41.2.15
+++ Block.java2 Mar 2003 13:47:44 - 1.41.2.16
@@ -185,8 +185,9 @@
area.end();
}
-if (area.getIDReferences() != null)
+if (area.getIDReferences() != null) {
area.getIDReferences().createID(id);
+}
this.marker = 0;
@@ -221,9 +222,6 @@
this.areasGenerated++;
if (this.areasGenerated == 1)
blockArea.isFirst(true);
-// for normal areas this should be the only pair
-//blockArea.addLineagePair(this, this.areasGenerated);
-
// markers
// if (this.hasMarkers())
// blockArea.addMarkers(this.getMarkers());
@@ -243,37 +241,25 @@
int numChildren = this.children.size();
for (int i = this.marker; i numChildren; i++) {
FONode fo = (FONode)children.get(i);
-int status;
-if (Status.isIncomplete(status = fo.layout(blockArea))) {
+int status = fo.layout(blockArea);
+if (Status.isIncomplete(status)) {
this.marker = i;
-// this block was modified by
-// Hani Elabed 11/27/2000
-// if ((i != 0) (status.getCode() == Status.AREA_FULL_NONE))
-// {
-// status = new Status(Status.AREA_FULL_SOME);
-// }
-
-// new block to replace the one above
-// Hani Elabed 11/27/2000
if (status == Status.AREA_FULL_NONE) {
-// something has already been laid out
-if ((i != 0)) {
-status = Status.AREA_FULL_SOME;
+if (i == 0) {
+// Nothing was laid out.
+anythingLaidOut = false;
+return status;
+} else {
+// A previous child has already been laid out.
area.addChild(blockArea);
area.setMaxHeight(area.getMaxHeight() - spaceLeft
+ blockArea.getMaxHeight());
area.increaseHeight(blockArea.getHeight());
anythingLaidOut = true;
-
-return status;
-} else// i == 0 nothing was laid out..
-{
-anythingLaidOut = false;
-return status;
+return Status.AREA_FULL_SOME;
}
}
-
-// blockArea.end();
+// Something has been laid out.
area.addChild(blockArea);
area.setMaxHeight(area.getMaxHeight() - spaceLeft
+ blockArea.getMaxHeight());
@@ -285,13 +271,10 @@
}
blockArea.end();
-
+blockArea.isLast(true);
+area.addChild(blockArea);
area.setMaxHeight(area.getMaxHeight() - spaceLeft
+ blockArea.getMaxHeight());
-
-area.addChild(blockArea);
-
-/* should this be combined into above? */
area.increaseHeight(blockArea.getHeight());
if (spaceAfter != 0) {
@@ -301,8 +284,6 @@
if (area instanceof BlockArea) {
area.start();
}
-// This is not needed any more and it consumes a LOT
-// of memory. So we release it for the GC.
areaHeight= blockArea.getHeight();
contentWidth= blockArea.getContentWidth();
@@ -311,18 +292,12 @@
int breakAfterStatus = propMgr.checkBreakAfter(area);
if (breakAfterStatus != Status.OK) {
this.marker = BREAK_AFTER;
-blockArea = null; //Faster GC - BlockArea is big
+blockArea = null;
return breakAfterStatus;
}
-
DO NOT REPLY [Bug 17472] - Images appear twice oin PDF output
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=17472. 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=17472 Images appear twice oin PDF output [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-03-02 13:53 --- Fixed (hopefully) for 0.20.5rc3. BTW while it's useful and positive that you supplied FO code (rather than random XML snippets), it's still of not much use without the image files. Also, problem reports with *small* but complete and self contained data get a higher priority than half-meg monsters. You was lucky I already tracked down the problem using another file. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
Hello, I reexamined the marker problematic again. There are a few issues not yet mentioned. First some odd wording: The properties of the fo:retrieve-marker impose a hierarchy of preference on the areas of the area tree... Unfortunately, they don't define this hierarchy directly but instead define how preferences are derived from this hierarchy. Every area in the hierarchy is considered preferential to, or better than, any area below it in the hierarchy. I suppose the 'hierarchy' mentioned here is the marker preference hierarchy rather than the area tree hierarchy. Further: When comparing two areas to determine which one is better, the terms first and last refer to the pre-order traversal order of the area tree. It's hard to see what purpose the marker preference hierarchy serves, as the real definition of the preferences is still done in terms of the area tree hierarchy. The quote above shows another problem: I'm used to the term pre-order in context of binary trees, where it means that first the first/left subtree is visited, then the node itself, then the last/right subtree. Unfortunately, the area tree is hardly a binary tree. How should the term be interpreted in this context? Let's take an example: fo:block id=A fo:marker marker-class=I id=m1/ fo:block id=B fo:marker marker-class=I id=m2/ ... /fo:block /fo:block Block B is, according to my interpretation of pre-order before block A, therefore retrieving class I with first-starting-within-page would get marker 2. Also, retrieving with either last-starting-within-page or last-ending-within-page should return marker m1. A common sense approach should probably yield first-starting-within-page: m1 last-starting-within-page: m2 last-ending-within-page: m1 The last one is of course debatable, there are arguments (using a glossary example) in favor of resulting in m2. If hierarchy in Every area in the hierarchy is considered preferential to, or better than, any area below it in the hierarchy. is interpreted as area tree hierarchy, always m1 would be retrieved, because the area generated by block A has both isFirst() and isLast() and is always above the area from block B. This interpretation is a bit better than the to the letter interpretation for first-starting-within-page and last-ending-within-page but doesn't really fit well for last-starting-within-page. Another interesting example fo:block id=A fo:marker marker-class=I id=m1/ fo:block id=B break-after=page fo:marker marker-class=I id=m2/ ... /fo:block /fo:block I interpret this that the area block A creates two areas, one of the first and one zero size area on the second page. Mind you, this is not at all clear from the spec, I more or less grabbed this out of the blue. The common sense result for the first page would mean last-ending-within-page returns m2. On the second page, every retrieve-position retrieves m1, of course. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 1130] - Alignment of page-number-citation inside a ToC
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=1130. 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=1130 Alignment of page-number-citation inside a ToC [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-03-02 16:56 --- Fixed for 0.20.5rc3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/render/xml XMLRenderer.java
pietsch 2003/03/02 08:55:19
Modified:.Tag: fop-0_20_2-maintain CHANGES
src/org/apache/fop/layout Tag: fop-0_20_2-maintain
FontState.java LineArea.java
src/org/apache/fop/layout/inline Tag: fop-0_20_2-maintain
InlineArea.java PageNumberInlineArea.java
WordArea.java
src/org/apache/fop/render Tag: fop-0_20_2-maintain
AbstractRenderer.java PrintRenderer.java
Renderer.java
src/org/apache/fop/render/awt Tag: fop-0_20_2-maintain
AWTRenderer.java
src/org/apache/fop/render/pcl Tag: fop-0_20_2-maintain
PCLRenderer.java
src/org/apache/fop/render/pdf Tag: fop-0_20_2-maintain
PDFRenderer.java
src/org/apache/fop/render/ps Tag: fop-0_20_2-maintain
PSRenderer.java
src/org/apache/fop/render/svg Tag: fop-0_20_2-maintain
SVGRenderer.java
src/org/apache/fop/render/txt Tag: fop-0_20_2-maintain
TXTRenderer.java
src/org/apache/fop/render/xml Tag: fop-0_20_2-maintain
XMLRenderer.java
Log:
Do text align before the line is rendered, not when the line is closed.
Moved page number resolving to just before text align. Removed page
number resolving from renderers.
Also, fix leader expansion in case page number resolving has eaten up
too much space for the page number, resolving in a possible area overflow.
Leaders may now be shortened down to leader-length.minimum if necessary.
PR: 1130, 17194
Revision ChangesPath
No revision
No revision
1.10.2.52 +2 -0 xml-fop/CHANGES
Index: CHANGES
===
RCS file: /home/cvs/xml-fop/CHANGES,v
retrieving revision 1.10.2.51
retrieving revision 1.10.2.52
diff -u -r1.10.2.51 -r1.10.2.52
--- CHANGES 2 Mar 2003 13:06:23 - 1.10.2.51
+++ CHANGES 2 Mar 2003 16:55:15 - 1.10.2.52
@@ -1,5 +1,7 @@
==
Done since 0.20.4 release
+- Fixed text alingment for lines containing forward pointing page number
+ citations. This should greatly improve TOC layout. (J.Pietschmann)
- Fixed repeatedly laid out small caps text (for example in static
content or due ot keeps). (J.Pietschmann)
- Fixed marker handling thouroughly. All retrieving boundaries and
No revision
No revision
1.14.2.8 +111 -7xml-fop/src/org/apache/fop/layout/FontState.java
Index: FontState.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/layout/FontState.java,v
retrieving revision 1.14.2.7
retrieving revision 1.14.2.8
diff -u -r1.14.2.7 -r1.14.2.8
--- FontState.java25 Feb 2003 14:07:03 - 1.14.2.7
+++ FontState.java2 Mar 2003 16:55:15 - 1.14.2.8
@@ -215,14 +215,118 @@
}
// Use default CodePointMapping
-char d = CodePointMapping.getMapping(WinAnsiEncoding).mapChar(c);
-if (d != 0) {
-c = d;
-} else {
-c = '#';
+char d = CodePointMapping.getMapping(WinAnsiEncoding).mapChar(c);
+if (d != 0) {
+c = d;
+} else {
+c = '#';
+}
+return c;
}
-return c;
+private int enWidth=-1;
+private int emWidth=-1;
+
+private final int getEmWidth() {
+if (emWidth0) {
+char mappedChar = mapChar('m');
+// The mapping returns '#' for unmapped characters in
+// standard fonts. What happens for other fonts?
+if (mappedChar == '#') {
+emWidth = 500 * getFontSize();
+} else {
+emWidth = width(mappedChar);
+}
+}
+return emWidth;
+}
+
+private final int getEnWidth() {
+if (enWidth0) {
+char mappedChar = mapChar('n');
+// The mapping returns '#' for unmapped characters in
+// standard fonts. What happens for other fonts?
+if (mappedChar != '#') {
+// Should do something to discover non-proportional fonts.
+enWidth = (getEmWidth()*9)/10;
+} else {
+enWidth = width(mappedChar);
+}
+}
+return enWidth;
+}
+
+/**
+ * Helper method for getting the width of a unicode char
+ * from the current fontstate.
+ * This also performs some guessing on
DO NOT REPLY [Bug 17194] - LineArea Leader fails in 0.20.5rc2
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=17194. 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=17194 LineArea Leader fails in 0.20.5rc2 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-03-02 16:57 --- Should be fixed for 0.20.5rc3. Long section lines may overflow the TOC line area, unless the leader permits shortening. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Encryption
Hey, Has anybody looked at this? It's been two weeks since I submitted it and I have not heard anything. Did I miss something? I'd like to get this included before the code base changes and I have to reimplement by hand. Pat Lankswert -Original Message- From: Patrick C. Lankswert [mailto:[EMAIL PROTECTED] Sent: Thursday, February 13, 2003 10:36 PM To: [EMAIL PROTECTED] Subject: Encryption To all that may concern, Here it is... PDF encryption. Unfortunately, I seem to be lame when it comes to cvs. When I generate the unified using WinCVS's cvs diff -uN, it does not include the file PDFEncryption.java. I have included it as a second attachment. It belongs in src/org/apache/fop/pdf. Send me all of your nice and nasty comments and I'll make any adjustments necessary. Enjoy, Pat Lankswert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Text alignment
Hello all, I just tried to fix the old page number expansion+alignment problem, which was bugging me for a looong time. I more or less made it. Well, here is my test file, and the problems are below: ?xml version=1.0? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:svg=http://www.w3.org/2000/svg; fo:layout-master-set fo:simple-page-master master-name=content page-width=300pt page-height=350pt fo:region-body margin-left=30pt margin-right=30pt/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=content fo:flow flow-name=xsl-region-body fo:block border-end-width=1pt border-end-style=solid text-align-last=justifyA1fo:leader leader-pattern=dots leader-length.maximum=20mm/fo:page-number-citation ref-id=A//fo:block fo:block border-end-width=1pt border-end-style=solid text-align-last=justifyAfo:leader leader-pattern=dots/fo:page-number-citation ref-id=A//fo:block fo:block border-end-width=1pt border-end-style=solid text-align-last=justifyBfo:leader leader-pattern=dots/fo:page-number-citation ref-id=B//fo:block fo:block border-end-width=1pt border-end-style=solid text-align-last=justifyCfo:leader leader-pattern=dots/fo:page-number-citation ref-id=C//fo:block fo:block border-end-width=1pt border-end-style=solid text-align-last=justifyDfo:leader leader-pattern=dots/fo:page-number-citation ref-id=D//fo:block fo:block border-end-width=1pt border-end-style=solid text-align-last=justifyEfo:leader leader-pattern=dots/fo:page-number-citation ref-id=E//fo:block fo:block border-end-width=1pt border-end-style=solid text-align-last=justifyFfo:leader leader-pattern=dots/fo:page-number-citation ref-id=F//fo:block fo:block border-end-width=1pt border-end-style=solid text-align-last=justifyGfo:leader leader-pattern=dots/fo:page-number-citation ref-id=G//fo:block fo:block border-end-width=1pt border-end-style=solid text-align-last=justifysuperduperlongGfo:leader leader-pattern=dots leader-length.maximum=100% leader-length.minimum=55% leader-length.optimum=60%/fo:page-number-citation ref-id=G//fo:block /fo:flow /fo:page-sequence fo:page-sequence master-reference=content fo:flow flow-name=xsl-region-body fo:block border-end-width=1pt border-end-style=solid text-align-last=endAfo:leader leader-pattern=dots/fo:page-number-citation ref-id=A//fo:block fo:block border-end-width=1pt border-end-style=solid text-align-last=endBfo:leader leader-pattern=dots/fo:page-number-citation ref-id=B//fo:block fo:block border-end-width=1pt border-end-style=solid text-align-last=endCfo:leader leader-pattern=dots/fo:page-number-citation ref-id=C//fo:block fo:block border-end-width=1pt border-end-style=solid text-align-last=endDfo:leader leader-pattern=dots/fo:page-number-citation ref-id=D//fo:block fo:block border-end-width=1pt border-end-style=solid text-align-last=endEfo:leader leader-pattern=dots/fo:page-number-citation ref-id=E//fo:block fo:block border-end-width=1pt border-end-style=solid text-align-last=endFfo:leader leader-pattern=dots/fo:page-number-citation ref-id=F//fo:block fo:block border-end-width=1pt border-end-style=solid text-align-last=endGfo:leader leader-pattern=dots/fo:page-number-citation ref-id=G//fo:block /fo:flow /fo:page-sequence fo:page-sequence master-reference=content initial-page-number=10 fo:flow flow-name=xsl-region-body fo:block id=AA/fo:block fo:blockfo:page-number//fo:block /fo:flow /fo:page-sequence fo:page-sequence master-reference=content initial-page-number=100 fo:flow flow-name=xsl-region-body fo:block id=BB/fo:block fo:blockfo:page-number//fo:block /fo:flow /fo:page-sequence fo:page-sequence master-reference=content initial-page-number=1000 fo:flow flow-name=xsl-region-body fo:block id=CC/fo:block fo:blockfo:page-number//fo:block /fo:flow /fo:page-sequence fo:page-sequence master-reference=content initial-page-number=1 fo:flow flow-name=xsl-region-body fo:block id=DD/fo:block fo:blockfo:page-number//fo:block /fo:flow /fo:page-sequence fo:page-sequence master-reference=content initial-page-number=111 fo:flow flow-name=xsl-region-body fo:block id=EE/fo:block fo:blockfo:page-number//fo:block /fo:flow /fo:page-sequence fo:page-sequence master-reference=content initial-page-number=9 fo:flow flow-name=xsl-region-body fo:block id=FF/fo:block fo:blockfo:page-number//fo:block /fo:flow /fo:page-sequence fo:page-sequence
Re: Encryption
Patrick C. Lankswert wrote: Has anybody looked at this? Yes. I'm currently in the process of integrating the stuff. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
J.Pietschmann wrote: Hello, I reexamined the marker problematic again. ... When comparing two areas to determine which one is better, the terms first and last refer to the pre-order traversal order of the area tree. ... The quote above shows another problem: I'm used to the term pre-order in context of binary trees, where it means that first the first/left subtree is visited, then the node itself, then the last/right subtree. Unfortunately, the area tree is hardly a binary tree. How should the term be interpreted in this context? Let's take an example: fo:block id=A fo:marker marker-class=I id=m1/ fo:block id=B fo:marker marker-class=I id=m2/ ... /fo:block /fo:block Joerg, More heart-in-the-mouth stuff for me, as I have coded the pre- and post-order iterators in Node according to another interpretation, and I have just had a mad search to try to justify it. From the DOM Level 2 Traversal and Range spec glossary: document order The term document order has the same meaning as depth first, pre-order traversal, which is equivalent to the order in which the start tags occur in the text representation of the document. In such an ordering, A precedes B. Block B is, according to my interpretation of pre-order before block A, therefore retrieving class I with first-starting-within-page would get marker 2. Also, retrieving with either last-starting-within-page or last-ending-within-page should return marker m1. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: HTML to FO
Title: RE: HTML to FO thats right... but the fo output from htmlfo is working properly... give it a go... cheers shyam -Original Message- From: Ken Masters [mailto:[EMAIL PROTECTED]] Sent: Saturday, March 01, 2003 11:09 PM To: [EMAIL PROTECTED] Subject: Re: HTML to FO From what I understand, htmlfo is an executable that converts html into FO, which can be directly plugged into Apache FOP. Now I saw somewhere that the html MUST NOT be correctly formed (I saw this on the souceforge page, I think). Is this correct? And how much is the output PDF similar to the original HTML? Thanks Ken _ It's fast, it's easy and it's free. Get MSN Messenger today! http://messenger.msn.co.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Encryption
Thanks... if there are any issues or work that is needed, I'm MORE than happy to help. Pat -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Sunday, March 02, 2003 12:35 PM To: [EMAIL PROTECTED] Subject: Re: Encryption Patrick C. Lankswert wrote: Has anybody looked at this? Yes. I'm currently in the process of integrating the stuff. J.Pietschmann - 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: Encryption
J.Pietschmann wrote: Patrick C. Lankswert wrote: Has anybody looked at this? Yes. I'm currently in the process of integrating the stuff. I'll have to do some more test, in particular for JDK1.3 compatibility (no javax.crypto there). Commit deferred to next Friday. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
JDK dependent files
Hi all,
do we have a policy how to name and where to store JDK dependent
source files?
The PDF encryption needs some stuff from 1.4 (would be nice if
someone knowledgable in the XML security project checked if there
are replacements). In order to compile FOP with 1.3, we need a
stub file (even if encryption were stuffed in via a filter
configuration, because of the command line options).
How should the files be named? Where should they be stored in order
to avoid them being picked up inappropriately by the build process?
We could
1. have a jdk1.3 and a jdk 1.4 directory below src, followd by the usual
org.apacheFileName.jave, exclude these dirs from build/copy and
conditionally copy the right files into the build tree
2. have a {jkd1.3|jdk1.4}/FileName.java below the package subdir and
exclude **/jdk*/** from build/copy (does this work?)
3. store the files elsewhere.
Once we have a policy, I'll convert the stuff currently filtered
to conditionally included classes too, it's easy.
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
FreshMeat entry
Hi all, and in particular Christian: the freshmeat.net entry lists FOP as version 0.17. What went wrong there? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Wrong operand type error in ASV 3.0
The error still persists even after I changed the width to 1. Swapan. --- Keiron Liddle [EMAIL PROTECTED] wrote: !-- If I remove this line, everything seems to work fine -- svg:line x1=58 y1=179 x2=403 y2=179 stroke=#00 stroke- width=0.5 / IIRC It is probably an error caused by this line being 0.5 width. In PDF lines can only be whole numbers and it might wrongly be inserting 0.5 in the PDF causing the error. Try making it width 1. If you need a 0.5 width line it can be scaled. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
