DO NOT REPLY [Bug 13451] - rendering of SVG with strokeSVGText = false causes exception
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=13451. 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=13451 rendering of SVG with strokeSVGText = false causes exception --- Additional Comments From [EMAIL PROTECTED] 2002-11-24 08:44 --- Provide an example, please. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Alt-Design status: XML handling
Peter B. West wrote: Why is it easier for developers to use? Is it because the API is less complex or more easily understood? Not really. As you point out, the SAX API is not all that complex. The problem is that the processing model of SUX is completely inverted. Well, I believe it's more philosophical question or a question of a programming style. push vs pull, imperative languages vs declarative languages etc etc etc ancient holy war. One likes to define rules aka sax handlers, another likes to weave a web from if statements, only to be able to control processing order ;) Both pull and push have pros and contras and it's a pity java still doesn't have a full-fledged pull parsing API (btw, James Clark is working on StAX[1], so it's a matter of time). You may have come to like writing XSLT that way. It's the only way to write non-hello-world stylesheets in xslt actually. Don't forget, xlst is a declarative language, so probably analogies with java are just irrelevant, they are different beasts. The question is what is good for the fo tree building stuff? Probably you right, pull is more suitable, but the bad thing is that real input is SAX stream hence we must translate push to pull (funny enough ms considers this task as unfeasible one in XMLReader documentation). Hence next question is the cost of your interim buffer, what do you think could be its peak and average size? Of course, as I have mentioned recently. And as I also said, the cost of parsing relative to the intensive downstream element processing of FOP is small. If so, isn't it too early to optimize xml handling altogether? What would we benefit from moving from push to pull? Well, sort of automatic validation is a benefit indeed, but I'm not sure it's enough. The whole question is context-dependent. If you are engaged in the peephole processing of SUX you may be obliged to use external validation. With top-down processing you have more choice, because your context is travelling with you. btw, what about unexpected content model objects? Will this fail? fo:simple-page-master master-name=default fo:region-body/ fo:block/ /fo:simple-page-master Don't get me wrong here. I'm not saying that external validation is wrong, merely that with a pull model, the need is reduced. There may still be a strong case for it, but not as strong as with SUX. You are right and that btw allows to make external validation optional and still to have reasonable level of validation for free. [1] http://www.jcp.org/en/jsr/detail?id=173 -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Opinion poll: Additional utility jars
Jeremias Maerki wrote: 1. Provide a big fop-complete.jar which contains among the fop classes all the utility packages with an Apache home (Commons, Avalon stuff). That's for easy use and involves repackaging of the utility jars during build. 2. Provide the same fop.jar as before but we'll have some more jars in out lib directory over time. This obviously means that the classpath will get some longer. IMO both has to be done, especially to service those who don't like a lot of jars in their classpath. Sounds reasonable. +1 -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Problems with examples
Peter B. West wrote: I have debugging my FO tree building be running it against various example fo files. Of the three I have used so far, I have found problems with two. ./docs/examples/pagination/allregions.fo has the problem that I mentioned in an earlier past; the simple-page-master does not have region-body as the first region specified. Hmmm, allregions.fo looks okay to me. Probably this stuff is also in tables/background.fo, this one really have fo:region-before extent=1cm/ fo:region-body margin-top=1cm/ fo:region-after extent=1.5cm/ btw, neither antenna nor XEP don't complain on it. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Problems with examples
Oleg Tkachenko wrote: Peter B. West wrote: I have debugging my FO tree building be running it against various example fo files. Of the three I have used so far, I have found problems with two. ./docs/examples/pagination/allregions.fo has the problem that I mentioned in an earlier past; the simple-page-master does not have region-body as the first region specified. Hmmm, allregions.fo looks okay to me. Probably this stuff is also in tables/background.fo, this one really have fo:region-before extent=1cm/ fo:region-body margin-top=1cm/ fo:region-after extent=1.5cm/ btw, neither antenna nor XEP don't complain on it. The FO spec is clear that the content is a sequence group. However, semantically, there's no point in constraining the order of occurrence in this case as there is no interdependenc of the elements. I'm sure that if XML had AND connectors the editors would have used them. Since there can be no practical failure that would result from a different order of region declarations, I think it's appropriate to not enforce the content model. In fact, I did a quick survey of all the formatting objects and this is the only case in which a sequence group is used where the order does not have some obvious purpose (e.g., putting declarations before uses). While any implementation would be free to complain if the order were not followed, I would consider that to be a Simon Says behavior--that is, complaining about something that could either be recovered from without risk or that cannot possibly hurt anything in the first place. I'm not sure how culturally distributed the childs' game of Simon Says is, but the basic idea is that one child gives orders and the other performs them IFF the first child says Simon Says, as in Simon says touch your nose or touch your nose (if the orderee complies, the first child says iperiously I didn't say Simon Says) (at least I think that's how it's played--it's been a long time since I played it and I have no children at hand to remind me of the details). In any case, I consider Simon Says behavior to be one of the more heinous sins of software implementation. It's especially prevelant in the implementation of standards, as one might expect. On the other hand, unrestrained recovery and fallback can lead to its own problems, as we learned from HTML. For example, I've found XSL Formatter's almost total lack of validation of FO instances to be counter productive in the long run if one is not checking their FO markup, either with XEP or by inspection against the spec. Fortunately, RenderX provides their validator as service to the community, so there's no excuse for anyone producing FO instances that don't at least conform to the rules XEP validates. Cheers, E. -- W. Eliot Kimber, [EMAIL PROTECTED] Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14809] New: - Static content in body on blank 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=14809. 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=14809 Static content in body on blank pages Summary: Static content in body on blank pages Product: Fop Version: 0.20.4 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When a blank page is generated, static content associated with the body-region on blank page is not generated. Usefull, to e.g. generate This page is intentionally left blank. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5335] - Text with embedded CID fonts not retrievable from pdf
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=5335. 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=5335 Text with embedded CID fonts not retrievable from pdf [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-11-24 16:07 --- I'm not sure it's a FOP's problem. Just tested occasional pdf with Japanese letters - http://www.morisawa.co.jp/font/info/pdf/AbtNewCID.pdf and it behaves the same way: I cannot copy'n'pase japanese text. I'll close the bug, but if you think I'm wrong, feel free to reopen it and provide an example, please. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14809] - Static content in body on blank 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=14809. 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=14809 Static content in body on blank pages --- Additional Comments From [EMAIL PROTECTED] 2002-11-24 16:07 --- Created an attachment (id=3935) blank-page region is not associated with xsl-region-body - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4002] - TTFReader unable to handle 3 of 9 Barcode font
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=4002. 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=4002 TTFReader unable to handle 3 of 9 Barcode font [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-11-24 16:57 --- The problem apparently is in your font. So either fix it by third-party font editor or try different one. For instanse this free bar code font works fine: http://www.squaregear.net/fonts/free3of9.shtml. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5047] - Dotted border style is not supported
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=5047. 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=5047 Dotted border style is not supported [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED Summary|Problem with border-style |Dotted border style is not ||supported - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 6638] - [PATCH] Enable auto portrait/landscape on PCL Renderer
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=6638. 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=6638 [PATCH] Enable auto portrait/landscape on PCL Renderer [EMAIL PROTECTED] changed: What|Removed |Added Summary|Enable auto |[PATCH] Enable auto |portrait/landscape on PCL |portrait/landscape on PCL |Renderer|Renderer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5235] - Font matching
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=5235. 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=5235 Font matching [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-11-24 17:58 --- See pdf 1.3 spec[1]: PDF prescribes a set of 14 standard fonts that can be used without prior definition. These include four faces of each of three Latin text typefaces (Courier, Helvetica*, and Times*) and two symbolic fonts (Symbol and ITC Zapf Dingbats®). These fonts, or suitable substitute fonts with the same metrics, are guaranteed to be available in all PDF viewer applications. And if Acrobat Reader indeed uses Arial MT to show Helvetica, what FOP has to do with it? Try different viewer or ask Acrobat Reader customer service. [1] http://partners.adobe.com/asn/developer/acrosdk/docs/filefmtspecs/PDFReference13.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo/flow Table.java
klease 2002/11/24 13:27:46
Modified:src/org/apache/fop/fo/flow Tag: fop-0_20_2-maintain
Table.java
Log:
Keep track of whether an area has been created so the continued label can be
generated
Revision ChangesPath
No revision
No revision
1.39.2.8 +175 -168 xml-fop/src/org/apache/fop/fo/flow/Table.java
Index: Table.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Table.java,v
retrieving revision 1.39.2.7
retrieving revision 1.39.2.8
diff -u -r1.39.2.7 -r1.39.2.8
--- Table.java22 Nov 2002 15:10:46 - 1.39.2.7
+++ Table.java24 Nov 2002 21:27:46 - 1.39.2.8
@@ -115,11 +115,11 @@
this.spaceAfter =
this.properties.get(space-after.optimum).getLength().mvalue();
this.ipd =
- this.properties.get(inline-progression-dimension).
- getLengthRange();
+this.properties.get(inline-progression-dimension).
+getLengthRange();
this.height = this.properties.get(height).getLength().mvalue();
this.bAutoLayout = (this.properties.get(table-layout).getEnum() ==
- TableLayout.AUTO);
+TableLayout.AUTO);
this.id = this.properties.get(id).getString();
@@ -184,20 +184,20 @@
boolean addedFooter = false;
int numChildren = this.children.size();
- // Set up the column ArrayList;
- // calculate width of all columns and get total width
- if (columns.size()==0) {
- findColumns(areaContainer);
- if (this.bAutoLayout) {
- log.warn(table-layout=auto is not supported, using fixed!);
- }
- // Pretend it's fixed...
- this.contentWidth =
- calcFixedColumnWidths(areaContainer.getAllocationWidth());
- }
+// Set up the column ArrayList;
+// calculate width of all columns and get total width
+if (columns.size()==0) {
+findColumns(areaContainer);
+if (this.bAutoLayout) {
+log.warn(table-layout=auto is not supported, using fixed!);
+}
+// Pretend it's fixed...
+this.contentWidth =
+calcFixedColumnWidths(areaContainer.getAllocationWidth());
+}
areaContainer.setAllocationWidth(this.contentWidth);
layoutColumns(areaContainer);
-
+
for (int i = this.marker; i numChildren; i++) {
FONode fo = (FONode)children.get(i);
if (fo instanceof TableHeader) {
@@ -269,6 +269,7 @@
}
setupColumnHeights();
status = Status.AREA_FULL_SOME;
+this.areasGenerated++;
}
return status;
} else {
@@ -285,6 +286,7 @@
}
}
}
+this.areasGenerated++;
if (tableFooter != null this.omitFooterAtBreak) {
if (Status.isIncomplete(tableFooter.layout(areaContainer))) {
@@ -342,9 +344,14 @@
return Status.OK;
}
+public void resetMarker() {
+this.areasGenerated=0;
+super.resetMarker();
+}
+
protected void setupColumnHeights() {
- for (int i = 0; i columns.size(); i++) {
- TableColumn c = (TableColumn)columns.get(i);
+for (int i = 0; i columns.size(); i++) {
+TableColumn c = (TableColumn)columns.get(i);
if ( c != null) {
c.setHeight(areaContainer.getContentHeight());
}
@@ -352,17 +359,17 @@
}
private void findColumns(Area areaContainer) throws FOPException {
- int nextColumnNumber = 1;
- for (int i = 0; i children.size(); i++) {
+int nextColumnNumber = 1;
+for (int i = 0; i children.size(); i++) {
FONode fo = (FONode)children.get(i);
if (fo instanceof TableColumn) {
TableColumn c = (TableColumn)fo;
c.doSetup(areaContainer);
int numColumnsRepeated = c.getNumColumnsRepeated();
int currentColumnNumber = c.getColumnNumber();
- if (currentColumnNumber == 0) {
- currentColumnNumber = nextColumnNumber;
- }
+if (currentColumnNumber == 0) {
+currentColumnNumber = nextColumnNumber;
+}
if (currentColumnNumber + numColumnsRepeated columns.size()) {
columns.ensureCapacity(currentColumnNumber +
numColumnsRepeated);
cvs commit: xml-fop/src/org/apache/fop/extensions ContinuedLabel.java ExtensionElementMapping.java
klease 2002/11/24 13:29:11 Modified:src/org/apache/fop/extensions Tag: fop-0_20_2-maintain ExtensionElementMapping.java Added: src/org/apache/fop/extensions Tag: fop-0_20_2-maintain ContinuedLabel.java Log: Implement a continued-label extension for use in tables Revision ChangesPath No revision No revision 1.4.2.4 +3 -1 xml-fop/src/org/apache/fop/extensions/ExtensionElementMapping.java Index: ExtensionElementMapping.java === RCS file: /home/cvs/xml-fop/src/org/apache/fop/extensions/ExtensionElementMapping.java,v retrieving revision 1.4.2.3 retrieving revision 1.4.2.4 diff -u -r1.4.2.3 -r1.4.2.4 --- ExtensionElementMapping.java 19 Nov 2002 01:03:58 - 1.4.2.3 +++ ExtensionElementMapping.java 24 Nov 2002 21:29:11 - 1.4.2.4 @@ -25,6 +25,7 @@ foObjs = new HashMap(); foObjs.put(outline, Outline.maker()); foObjs.put(label, Label.maker()); +foObjs.put(continued-label, ContinuedLabel.maker()); } } @@ -45,3 +46,4 @@ } } + No revision No revision 1.1.2.1 +108 -0xml-fop/src/org/apache/fop/extensions/Attic/ContinuedLabel.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/image FopImageFactory.java
klease 2002/11/24 13:35:14
Modified:src/org/apache/fop/image Tag: fop-0_20_2-maintain
FopImageFactory.java
Log:
Hook up the TiffImage to the factory; falls back to generic handler if not present
Revision ChangesPath
No revision
No revision
1.25.2.7 +7 -2 xml-fop/src/org/apache/fop/image/Attic/FopImageFactory.java
Index: FopImageFactory.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/image/Attic/FopImageFactory.java,v
retrieving revision 1.25.2.6
retrieving revision 1.25.2.7
diff -u -r1.25.2.6 -r1.25.2.7
--- FopImageFactory.java 18 Nov 2002 14:37:45 - 1.25.2.6
+++ FopImageFactory.java 24 Nov 2002 21:35:14 - 1.25.2.7
@@ -144,7 +144,12 @@
} else if (image/eps.equals(imgMimeType)) {
imgClassName = org.apache.fop.image.EPSImage;
} else if (image/tiff.equals(imgMimeType)) {
-imgClassName = getGenericImageClassName();
+try {
+imgClassName = org.apache.fop.image.TiffImage;
+Class.forName(imgClassName);
+} catch (Exception ex) {
+imgClassName = getGenericImageClassName();
+}
} else if (image/svg+xml.equals(imgMimeType)) {
imgClassName = org.apache.fop.image.SVGImage;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5335] - Text with embedded CID fonts not retrievable from pdf
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=5335. 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=5335 Text with embedded CID fonts not retrievable from pdf [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-11-25 00:33 --- I think that this is FOP's problem caused by wrong CMap. I can copy and paste japanese text http://www.morisawa.co.jp/font/info/pdf/AbtNewCID.pdf , because this pdf file is collectly generated. FOP use the value of 'UCS' as the CIDSystemInfo of PDF. And FOP allocate with original sequential value for each glyph. When you copy and paste any text, PDFReader try to encode to correct character encoding (for examples, Adobe-Japan-1), but there is no information to mapping. If you want to copy and paste, FOP must create PDF using correct Encoding and CIDSystemInfo. These kind of problem's details, see http://marc.theaimsgroup.com/?l=fop-devm=101408636328343w=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5335] - Text with embedded CID fonts not retrievable from pdf
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=5335. 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=5335 Text with embedded CID fonts not retrievable from pdf --- Additional Comments From [EMAIL PROTECTED] 2002-11-25 00:35 --- Created an attachment (id=3939) Japanese sample pdf and fo files generated by FOP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
