Re: Linebreaks around e-g and i-f-o
I agree that a) is probably best. See e-g/i-f-o just like a glyph in a word, for example. At least, it could be used that way. In most situations you'll probably surround the graphic with spaces anyway, so break possibilities come from there. On 09.11.2005 05:51:03 Manuel Mall wrote: What's the opinion around the group on how external-graphics / instream-foreign-objects are suppose to be handled with respect to determining linebreak opportunities. a) There is no intrinsic linebreak opportunity on either side of an e-g/i-f-o (of course if surrounded by spaces or other breaking chars these will produce a linebreak opportunity) Knuth sequence: box w=... b) They act more like a word surrounded by zero width spaces, ie one can break before and after. Knuth sequence: pen w=0 p=0 box w=... pen w=0 p=0 c) Like b) but its undesirable so we penalise it, like a hyphen. Knuth sequence: pen w=0 p=FLAGGED box w=... pen w=0 p=FLAGGED d) Some (weird) combination like only allow a break after a) is certainly the simplest and an author can always put a ZWSP around an e-g/i-f-o element. But would the average user expect it to behave more like b) or c) (FWIW - MS Word behaves more like b)? On the other hand for b) and c) we need an override if an author doesn't want a break, ie. an explicit zero width joiner would be required. I am tending towards a). Manuel Jeremias Maerki
DO NOT REPLY [Bug 37417] - Patch to support fop from partially implemented Class Loaders.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37417. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37417 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-11-09 09:12 --- Patch applied: http://svn.apache.org/viewcvs?rev=331991view=rev Thanks for catching that. One request, though: Please attach patches as a file to Bugzilla issues. Bugzilla tends to add additional line breaks to the patch if included in comments. It was no problem in this case (just one additional line break), but with bigger patches this will become a problem. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Inquiry: conditional inclusion of dev-related debugging?
[Andreas]
Hi all,
For starters: it's not really a pressing matter ATM, but it may become
of relevance if we want to strive for a production-release. The matter
is somewhat related to the distinction between developer- and
user-directed logging.
It concerns the numerous log.debug() and log.trace() messages scattered
around. Just recently, I was reminded of a little Java trick that
emulates C's conditional compilation, which inspired me to pop this
question here.
As you are most likely well aware, every log.debug() generates bytecode
at compile-time, which leads to compiled classes being unnecessarily
large for general usage. In Java, there exists this little trick to
define a final debug() method:
final void debug(String msg) {
if (DEBUG) {
log.debug(msg);
}
}
The DEBUG boolean constant being defined in a central, easily
accessible place.
If subsequently, all log.debug() calls are replaced by mere debug(),
and one sets DEBUG to false, then the result at compile-time is that:
- there is no bytecode generated for the debug() methods (empty body)
That is true.
- since the method is final, and it has an empty body, the compiler can
optimize further and no bytecode will be generated for any call to it.
Not true for javac from jdk1.4.2. A call to the debug method is included
in the byte code. Perhaps other compilers does it differently.
Meaning also: possible string literals in the message do not take up
space in the internalized string-table, which in turn would be
beneficial for eventual runtime-calls to String.intern() (smaller table
= decreased lookup-time)
Also not true for 1.4.2.
public class x {
public static final boolean DEBUG = false;
public static void main(String[] args) throws Exception {
new x();
}
public x() {
int i = 55;
debug(hello + i + world);
}
final void debug(String msg) {
if (DEBUG) {
System.out.println(msg);
}
}
}
Compiled from x.java
public class x extends java.lang.Object{
public static final boolean DEBUG;
public static void main(java.lang.String[]);
throws java/lang/Exception
Code:
0: new #1; //class x
3: dup
4: invokespecial #2; //Method init:()V
7: pop
8: return
public x();
Code:
0: aload_0
1: invokespecial #3; //Method java/lang/Object.init:()V
4: bipush 55
6: istore_1
7: aload_0
8: new #4; //class StringBuffer
11: dup
12: invokespecial #5; //Method java/lang/StringBuffer.init:()V
15: ldc #6; //String hello
17: invokevirtual #7; //Method
java/lang/StringBuffer.append:(Ljava/lang/String;)Ljava/lang/StringBuffer;
20: iload_1
21: invokevirtual #8; //Method
java/lang/StringBuffer.append:(I)Ljava/lang/StringBuffer;
24: ldc #9; //String world
26: invokevirtual #7; //Method
java/lang/StringBuffer.append:(Ljava/lang/String;)Ljava/lang/StringBuffer;
29: invokevirtual #10; //Method
java/lang/StringBuffer.toString:()Ljava/lang/String;
32: invokevirtual #11; //Method debug:(Ljava/lang/String;)V
35: return
final void debug(java.lang.String);
Code:
0: return
}
All the string litterals and string concatination still exists in the
byte code.
Perhaps the JIT will detect the empty method and avoid the string
concatination, I have not tested that, but I doubt it.
regards,
finn
DO NOT REPLY [Bug 36480] - [PATCH] Space support in RTF rendering
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36480. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36480 --- Additional Comments From [EMAIL PROTECTED] 2005-11-09 10:16 --- Sergey, I'm sorry I have to annoy you again. Now that your CLA is on file I wanted to revisit this patch and I realized that I have trouble determining exactly how this patch affects the handling of FO. Would you please also post your test files so I can easily reproduce what you were after. Thanks a lot! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36826] - nullpointerexc at org.apache.fop.fo.FOTreeBuilder.endElement, XSL and XML are valid
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36826. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36826 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-11-09 10:20 --- Not enough information to reproduce, so I'm closing this bug. Please reopen if you still have the problem and you have a test file to reproduce it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36952] - FopServlet.java in servlet examples
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36952. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36952 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2005-11-09 10:33 --- Your issue slipped through the cracks, sorry. The problem is not with FOP, but with Oracle's XML parser or XSLT implementation. As shown in [1] the problem seems to be solvable only by replacing Oracle's parser and XSLT implementation with Apache's Xalan-J and Xerces-J or another package. At least three people had this problem so far. Someone should really file a bug with Oracle so they fix their bug. [1] http://www.nabble.com/Problem-with-10g-Parser-t447344.html -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 37116] - ESC POS Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37116. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37116 --- Additional Comments From [EMAIL PROTECTED] 2005-11-09 10:36 --- I'd like additional opinions from the FOP committers on this one. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 37253] - [PATCH] At present rendering to TXT is unimplemented.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37253. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37253 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO Keywords||PatchAvailable Summary|At present rendering to TXT |[PATCH] At present rendering |is unimplemented. |to TXT is unimplemented. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 37116] - ESC POS Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37116. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37116 --- Additional Comments From [EMAIL PROTECTED] 2005-11-09 12:45 --- Well if the code follows the Project style conventions has the Apache header, and works for Trunk then the only Pro/cons I see to commiting this to the code base are: + An additional renderer which may be useful for some users - although I think its a very tiny set of users. XSL-FO is not the best tecnology for working with ESCPOS Printers, but then XSL-FO is not the best technology for generating Text output either. - Support problems; users on the mailing list asking what it does, or reporting that it doesn't do X or Y. Given the above it's a hard decision to make :) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 37253] - [PATCH] At present rendering to TXT is unimplemented.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37253. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37253 --- Additional Comments From [EMAIL PROTECTED] 2005-11-09 13:15 --- Created an attachment (id=16923) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16923action=view) Fixed previous patch for txt Sorry for a lot of warnings. Fixed. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 37116] - ESC POS Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37116. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37116 --- Additional Comments From [EMAIL PROTECTED] 2005-11-09 13:44 --- I have similar concerns as Chris. Maybe once we have the pluggable renderers this can be more easily solved by a) People who develop non mainstream renderers can provide them as separate jars and house them on SourceForge or similar environments b) The FOP project itself could have an area called unsupported for this type of additions to FOP c) XMLGraphics could provide an incubator type environment for it It seems what I am saying is that we should encourage and support expansion / extension of FOP by possibly providing some infrastructure for it but not necessarily by adding everything into the core code base. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Preparing for the first release
The time has come and we need to push FOP out to the public again, at least IMO. I'm currently seeing through the last few things (patches, docs, bugs etc.). Are there any objections on doing the first release within the next few days? Is there anything that needs to be done which is not on the release plan [1] besides the sandbox proposal? Does anyone see any outstanding legal issues preventing the release as is? Anything else? I think I can live with the current API for now (after my imminent changes as announced) although I would not see it as fixed for the first production-ready release, yet. I will want a big disclaimer about the API stability in the release notes. Remember the first preview release doesn't need to be perfect. It should do something reasonable and not crash with every second document. But many people will only start playing with the new code when we release it. Christian, are you available for managing the actual release (build plus deployment)? [1] http://wiki.apache.org/xmlgraphics-fop/ReleasePlanFirstPR Jeremias Maerki
DO NOT REPLY [Bug 37116] - ESC POS Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37116. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37116 --- Additional Comments From [EMAIL PROTECTED] 2005-11-09 15:07 --- May i suggest (In reply to comment #11) Well if the code follows the Project style conventions has the Apache header, and works for Trunk then the only Pro/cons I see to commiting this to the code base are: + An additional renderer which may be useful for some users - although I think its a very tiny set of users. XSL-FO is not the best tecnology for working with ESCPOS Printers, but then XSL-FO is not the best technology for generating Text output either. Its true. But what if your printer supports only two fonts? This renderer render eye visible text but it is really an image with gliphs for characters from any fop supported font, and XSL-FO lets you align things on a preprinted form simply with a ruler, millimeter by millimeter an not with \n \r \something. - Support problems; users on the mailing list asking what it does, or reporting that it doesn't do X or Y. Given the above it's a hard decision to make :) Just trying to explain. Andrea -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Sandbox area for renderers
Jeremias Maerki wrote: Given the recent comments concerning the ESP POS renderer, it looks like it would make sense to put certain renderers in a separate area. In Barcode4J I have a src/sandbox area. Self-speaking, I guess. Also taking the state that MIF, PCL and SVG output are in, it would be better to move them there and make them optional until they are usable again. Good idea. It doesn't make sense for those renderers to be in the first preview release. With my changes to be committed the command-line could be adjusted to only expose the output options that are available in the class loader setup. No big deal in that. It would also help send the right signals to our users. Some people might expect the PCL renderer to have the same quality as in 0.20.5. But PCL support is simply not there right now. I personally wouldn't call the area unsupported as Manuel suggested. sandbox would send a better signal IMO. Furthermore, I don't like an incubator area so much because that could be easily confused with the Incubator project. Makes sense. I can take care of the necessary moves/changes, if we can agree on a course here. I hope we can get there fast, because I would really like to push out this first preview release ASAP and within the next days and because this is something that should be done prior to the release. So what I would suggest: - Create src/sandbox. - Move the MIF, PCL and SVG output to src/sandbox. - Adjust the build to create a fop-sandbox.jar which dynamically registers the output formats when they are in the classpath. - Add the ESC POS renderer to src/sandbox. WDYT? +1 from me. Chris
DO NOT REPLY [Bug 37305] - Added deviceDPI to PDFDocumentGraphics2D
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37305. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37305 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2005-11-09 16:09 --- I've got a question on this one: How does the setDeviceDPI() relate to the resolution setting in the user agent? So far I was able to set a different resolution on the user agent to get PDFs with higher resolution on-the-fly images. I'm not sure but it seems that this isn't working properly anymore. Can't tell when this went lost. And AFAICS setDeviceDPI() is not called by the Transcoder. Is that by design? I'm a bit lost. Concerning preparePainting(), we may need to add additional calls where necessary. I've added this method to support multi-page PDFs from PDFDocumentGraphics2D. I'm using it in a JPS StreamPrintService where you don't know beforehand if the next page will be produced or not. A call to nextPage() finishes the current page and a new one can only be set up when painting begins. So for single page SVGs from the Transcoder, your change is fine, but we may need to add additional calls where needed. I'll have a look when I start moving the transcoders as I will publish my JPS StreamPrintService at that time. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Sandbox area for renderers
On Wed, 9 Nov 2005 09:50 pm, Jeremias Maerki wrote: snip/ I personally wouldn't call the area unsupported as Manuel suggested. sandbox would send a better signal IMO. Furthermore, I don't like an incubator area so much because that could be easily confused with the Incubator project. Fine with me. I can take care of the necessary moves/changes, if we can agree on a course here. I hope we can get there fast, because I would really like to push out this first preview release ASAP and within the next days and because this is something that should be done prior to the release. So what I would suggest: - Create src/sandbox. - Move the MIF, PCL and SVG output to src/sandbox. - Adjust the build to create a fop-sandbox.jar which dynamically registers the output formats when they are in the classpath. - Add the ESC POS renderer to src/sandbox. WDYT? +1 Jeremias Maerki Manuel
Re: svn commit: r332007 - /xmlgraphics/fop/trunk/test/fotree/testcases/no_namespace_prefix.fo
On Wed, Nov 09, 2005 at 08:58:24AM -, [EMAIL PROTECTED] wrote: Author: jeremias Date: Wed Nov 9 00:58:20 2005 New Revision: 332007 URL: http://svn.apache.org/viewcvs?rev=332007view=rev Log: Test to check FO tree building when no namespace prefix is used. Why is this necessary? Doesn't the parser resolve the prefix and then hide it from FOP? Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: svn commit: r332007 - /xmlgraphics/fop/trunk/test/fotree/testcases/no_namespace_prefix.fo
I know it's not strictly necessary. It's just there for regression testing purposes and as a demonstration that you don't have to use the fo: prefix. It doesn't hurt, does it? On 09.11.2005 21:38:32 Simon Pepping wrote: On Wed, Nov 09, 2005 at 08:58:24AM -, [EMAIL PROTECTED] wrote: Author: jeremias Date: Wed Nov 9 00:58:20 2005 New Revision: 332007 URL: http://svn.apache.org/viewcvs?rev=332007view=rev Log: Test to check FO tree building when no namespace prefix is used. Why is this necessary? Doesn't the parser resolve the prefix and then hide it from FOP? Jeremias Maerki
Re: White space handling Wiki page
On Tue, Nov 08, 2005 at 11:19:15AM +0800, Manuel Mall wrote: On Tue, 8 Nov 2005 04:40 am, Simon Pepping wrote: Step 2. Refinement: white-space-collapse Issue 1. The spec intentionally addresses only XML white space, because only such white space is manipulated by editors to obtain pretty printing. Point taken, although I have no experience with non western editors. Do they all use 0x20 for 'pretty printing'? The XML spec does not allow one to use other characters than XML white space for pretty printing, at least not in element content. It would result in an invalid XML file because PCDATA would be present where the DTD or schema does not allow it. That is even true for non-breaking-space, U+A0. ul liSome text./li /ul is valid XHTML, but ul #xA0;#xA0;#xA0;#xA0;liSome text./li /ul is not. In PCDATA it is slightly different. p This is some content. We wrap the lines at a narrow width. /p Formally these data are different from the case when the text of the paragraph were written in one line: spaces have been converted to linefeeds, and sequences of spaces have been inserted. The XML parser reports all linefeeds and spaces as character data to the application. But almost all applications treat the two cases as equivalent, certainly when the data are considered as textual data. It is exactly this convention that the FO spec tries to formalize. fo:block This is some content. We wrap the lines at a narrow width. /fo:block _is_ equivalent to the case when the text of the block were written in one line, due to the line-feed-treatment and white-space-collapse properties (at default values). Such a convention is not usually applied to non-XML-whitespace characters, and the FO spec shows no intention to do so. A side effect is that 'This is some content' is equivalent to 'This is some content', but that is not the case with any other character, even if that is considered as white space in some script. Example 2 = The space in fo:block.fo:block is suppressed because it is at the start of the block. Interesting - I agree that this is the intention but you don't find that sentence in the spec. In 1.1 this is covered by the deleting spaces at the beginning of a line under white-space-treatment / line building. Again the discussion is probably academic - we all agree what the expected outcome is. If we can derive that outcome from the spec or not is a very interesting discussion but won't change what we will do. This is convered under the notion that the start and end of an fo:block are equivalent to line breaks. And fo:blockfo:block does not generate an empty line. fo:block starts a new line, but that is not equivalent to a linefeed. When at the start of the nested fo:block there is no content in the line yet, it starts the same line. A similar thing happens in the case of /fo:block#x0A;/fo:block, which was discussed in an email thread. I assume you mean the discussion under linefeed-treatment=preserve. I am still confused about that because /fo:block#x0A;#x0A;/fo:block will generate one linefeed or should this create also none? Yes, I am referring to that discussion, and I quoted it wrong. The case is: #x0A;/fo:block. The linefeed creates a linebreak, /fo:block does not add another one since the line has already been ended. /fo:block#x0A;/fo:block should create one empty line, and /fo:block#x0A;#x0A;/fo:block two empty lines, I suppose. Nowhere in the spec is a conversion of tabs and CRs to spaces specified. Under 7.15.8 it says: preserve Specifies that any character flow object whose character is classified, before any linefeed-treatment handling is considered, as white space in XML, except for U+000A (linefeed) characters, shall be converted during the refinement process into a character flow object whose Unicode code point is U+0020 (space). But they removed it in 7.16.8 in the 1.1 draft. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Linebreaks around e-g and i-f-o
Manuel Mall wrote: What's the opinion around the group on how external-graphics / instream-foreign-objects are suppose to be handled with respect to determining linebreak opportunities. FOP 0.20.5 implemented b). I read the UAX14 catch all rule LB20 the way that it also recommends b). J.Pietschmann
DO NOT REPLY [Bug 37305] - Added deviceDPI to PDFDocumentGraphics2D
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37305. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37305 --- Additional Comments From [EMAIL PROTECTED] 2005-11-10 02:48 --- (In reply to comment #2) I've got a question on this one: How does the setDeviceDPI() relate to the resolution setting in the user agent? So far I was able to set a different resolution on the user agent to get PDFs with higher resolution on-the-fly images. This working depends heavily on the way the SVG is constructed, also it can have some very unexpected (read harmful) results. The pixel per mm setting is used to map 'real world' units (like in, mm, pt, px - yes px is a real world unit in SVG because it's defined == to pt) to user space units. So in the default case let's say we have the User Agent setup so 1pt == 1 user space unit (1in = 72 user space units), and you have a 'good' outermost SVG element: svg width=8in height=10in viewBox=0 0 576 720 xmlns=... In this case your width and height establish a 'device' image size of 8*72x10*72 (576x720) user space units. Since the viewBox is the same size there will be no scaling. Now if you were to set the mapping to say 144 user space units to the inch. Then the device image size would be 8*144x10*144 (1152x1440) user space units. However the viewBox would scale this back down to 576x720. The PDF transcoder adds a 'hidden' scale from the PDF page size to the 1152x1440 page size (much as my code does). So far everything looks good, but the problem is that when someone says text font-size=12pt/ this gets mapped to 24 userspace units instead of 12 userspace units. I'm not sure but it seems that this isn't working properly anymore. Can't tell when this went lost. And AFAICS setDeviceDPI() is not called by the Transcoder. Is that by design? I'm a bit lost. You are right that it isn't currently called. The problem is that it should really be exposed as a new rendering hint. In my patch I didn't change the 'default' DPI but it should really be set to 150 or 300 dpi. Concerning preparePainting(), we may need to add additional calls where necessary. I've added this method to support multi-page PDFs from PDFDocumentGraphics2D. I'm using it in a JPS StreamPrintService where you don't know beforehand if the next page will be produced or not. A call to nextPage() finishes the current page and a new one can only be set up when painting begins. So for single page SVGs from the Transcoder, your change is fine, but we may need to add additional calls where needed. I'll have a look when I start moving the transcoders as I will publish my JPS StreamPrintService at that time. I strongly suspected that the missing calls were an oversite, but before making such extensive changes I wanted to make sure. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Linebreaks around e-g and i-f-o
On Thu, 10 Nov 2005 09:34 am, Andreas L Delmelle wrote: On Nov 9, 2005, at 23:38, J.Pietschmann wrote: Manuel Mall wrote: snip/ Now, I have another question / remark. Look at InlineCharIterator: the boundary EOT characters for start and end of the inline, are they passed on to Layout? No they are not. CharIterator is only used during the refinement step by the fo.Block object and the EOT character is only used by the refinement step as a boundary indicator. It is not stored nor passed to layout. snip/ Cheers, Andreas
