DO NOT REPLY [Bug 37236] - Fix gradients and patterns
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=37236. 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=37236 --- Additional Comments From [EMAIL PROTECTED] 2005-10-25 09:02 --- (In reply to comment #1) snip/ 2) Patterns that contain gradients generate 'bad' PDF.I suspect the problem is resource referencing. Since I am fairly sure the problem existed before my fidling I'm going to leave it as is. Do you have a test case to reproduce this? 3) Patterns with 'overflow=visible' ignore overflow. Number 3 is pretty simple to fix (just need to render the gn content multiple times to make the tile). I suspect Number 2 is not too hard if you understand PDF (which I don't really). Number 1 would require adding support for rasterizing unknown paint's and using that as a pattern fill (just make the size of the pattern fill the same as shape being painted). A few notes on the patch. 1) I simplified the PDFState.Data class, by removing the the 'concatenations' List. It doesn't seem to be used by anything. You're wrong. It is used by the PDF Renderer to handle fixed positioned block-containers. This can't just be removed. The concatenate() method even has a proper javadoc comment that explains the purpose. 2) I changed PDFState.getTransform it now just returns the current transform as this already includes all the previous transforms.Perhaps I misunderstood the code but things work now and the transforms make sense where as they didn't before. As you can see in my comment for 1) this can't be the solution. If you can give be the test cases that are involved here I can try to help. 3) I added the ability to provide a transform to PDFFactory.makeGradient this is required to handle some of the more complex cases of gradients with non-uniform scaling transforms. -- 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 37236] - Fix gradients and patterns
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=37236. 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=37236 --- Additional Comments From [EMAIL PROTECTED] 2005-10-25 09:04 --- (In reply to comment #2) Created an attachment (id=16800) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16800action=view) [edit] Update that support patterns with overflow=visible This version of the patch supports overflow on patterns but it requires the SVN version of Batik as I needed to add access to the 'overflow' member of the PatternPaint class. For this reason I didn't obsolete the previous patch. Ok, but that part might have to wait until after the first FOP release since we need to be able to ship a Batik release. The other option is to do a bugfix release for Batik. I assume that would be a good idea anyway given the number of recent changes. -- 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: White space handling Wiki page
Hi, I haven't got any technical comments to the issues raised on the Wiki page. Is this 'too hard' or 'too boring' or 'too messy' or what? The problem is not going away. We currently don't do it right in some parts (that is established) but I don't know overall what is right or wrong. May be if I ask for comments on an issue by issue basis we get somewhere? Quick background: In the default case (which seems to be the most complicated) white space handling consists of 3 things - a) Replace any white space that is not as space char with a space char = easy. b) Collapse any sequence of spaces to a single space. c) Remove any spaces at the beginning and end of lines. First issue for b) and c) (and it may have different answers for b) and c)): In other places the spec has a concept of a fence as a boundary across which certain operations do not apply, e.g. space resolution. When FOP is collapsing (b) or removing (c) white space are there any fences we need to observe. For example a border/padding between two spaces, e.g. (spaces represented by a .): fo:block...fo:inline border=..Text .../fo:inline.../fo:block There are 4 sequences of 3 spaces each. What would we expect the final outcome to be (assuming it fits on one line): a) all removed: [border]Text[border] b) only first and last removed: [border].Text.[border] c) first, 2nd and last removed: [border]Text.[border] d) ??? To me b) makes sense. However, a) is the HTML way and c) seems what RenderX and AntennaHouse are doing. What do we want to do? And what about this: fo:block...A...fo:inline border=..Text .../fo:inline...B.../fo:block a) all removed: A[border]Text[border]B b) only first and last removed: A.[border].Text.[border].B c) only first and last removed and others collapsed across the borders: A.[border]Text.[border]B d) ??? a) is most likely wrong, b) looks OK, c) is the HTML way. Manuel
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-10-25 16:05 --- Created an attachment (id=16808) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16808action=view) coding style touced-up -- 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.
Why is / is valid line breaking char in FOP?
My apologies if that has been discussed before. While investigating if we could use the standard java.text.BreakIterator to determine line break points I noticed that FOP uses in addition to space, zero width space, hyphen also the forward slash as a valid line breaking character. The Java BreakIterator does not recognize slash as a line breaking char (nor FWIW does MS Word). What is the background to FOP allowing this? Is this consistent with normal user expectations or is this specific to type setting environments / Tex / Knuth? Regards Manuel
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-10-25 16:35 --- Probably you are right, there may be someone somewhere that wants to print invoices with Vectorial Graphics or whatever, but writing a good java library to support escpos printers needs time, writing a FOP Renderer to easly print a page is a starting point... I've tyde up the code, and recoded for the trunk you posted me out. Andrea (In reply to comment #7) (In reply to comment #6) (In reply to comment #2) Andrea, thank you for this. I think support for these POS printers is interesting, though I'm not sure this is the best approach to implement this. I think you could create a much more universally usable thing if you took the bitmap conversion out of the renderer and into a separate package where you simply take bitmap images that you convert for the POS printers. That way it could easily be used for FOP Trunk, too. Yes, but is really useless without FOP. Those printers are almost used to print receipts and invoices, with near to 0 support for advanced imaging, so this will be used almost to line up text on preprinted forms, and i think it is a very easy way to do it. It may be useless without FOP in your case, but some people might actually want to create the receipts with SVG/Batik instead of XSL-FO/FOP. I simply think you restrict your code too quickly to a certain use case while it could actually be used in a much wider area. After all, we won't be able to include your renderer in FOP as is, (1) because it's apparently written for FOP 0.20.5 whose development line has been frozen and (2) your code would need some touch-up before we would include it (code style, package name must be org.apache.fop.*, no apache license header etc.). I posted it with package and header, but is there a doc with coding style infos that i can use to touch-up the code? Our code conventions: http://xmlgraphics.apache.org/fop/dev/conventions.html And you can take the existing code as an example. Which branch i should use? No branch. Use the trunk: http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/ BTW, the license header needs to be the one from the Apache License v2.0, not 1.1. If I were you, separate this code out into a universally usable component that can convert bitmaps to output for POS printers and post that somewhere on the net, for example as SourceForge project. We could then link to it from the FOP website. WDYT? As i say i think it is really useless alone. And I disagree. :-) -- 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.
2 weeks offline
Hi all, I'll be offline from tomorrow for 2 weeks: visiting Japan. Although I don't have had much time to work on Fop those last days I don't abandon my work. I've taken a little break in the adaptation to learn a bit of PDF. I think this is necessary to better understand what I'm doing. The AWT renderer should now fully work. I've recently had a long discussion with Victor to properly handle fonts for both screen and print outputs; it is now possible to map the FO generic font names (serif, sans-serif, monospace) to either the default awt fonts (corresponding to the Lucida family), or to the Times/Helvetica/Courier families. This should help having the same result for both types of outputs. As the RTF renderer doesn't seem to depend on the font subsystem at all, I guess it should work fine as well. What's left : correct a little problem with CID fonts in the PDF renderer, adapt the PS renderer (which should be much easier now), adapt the SVG library for PDF and PS. Cheers, Vincent
Re: White space handling Wiki page
Hi Manuel, On Tue, Oct 25, 2005 at 04:57:41PM +0800, Manuel Mall wrote: Hi, I haven't got any technical comments to the issues raised on the Wiki page. Is this 'too hard' or 'too boring' or 'too messy' or what? The problem is not going away. We currently don't do it right in some parts (that is established) but I don't know overall what is right or wrong. May be if I ask for comments on an issue by issue basis we get somewhere? You and Jeremias both turning in so much work is too much to follow. I really would like to comment on your analysis, but I do not right now have time for it. Perhaps in one of the next weeks. Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: RTF output
On Oct 25, 2005, at 00:20, Tony Morris wrote:
I don't have my test case with me, since I am at work at the moment.
Otherwise, what I recall is setting the size of an external-graphic
to the
exact number of pixels (I think if I didn't, the RTF renderer
wasn't happy),
the image appeared scaled down, but if I set the image size to say,
10x the
number of pixels, it would not appear 10x bigger than the scaled
down image,
but about the size I would expect normally. Granted, I was using MS
Word
2003 for verification, which may well be the culprit.
(cc'ing fop-dev, since the message contains pointers on the causes of
this problem, and may help someone devise a solution for it)
Well, we shouldn't be blaming M$ for everything --however tempting it
may be ;-)
All I can say is that the other renderers all use the same set of
image library wrappers. The RTF renderer currently is the only
exception (support for external-graphics was reintroduced for RTF
about a month ago).
AFAICT, in the long run, it's the intention of switching to the same
set of wrappers for the RTF renderer. Doing so could mean that your
problem disappears, I'm not sure. What is more than certain is that
the current code in the RTF lib is not 100% correct, and even seems
to make the same mistake in interpretation of the related properties
(height/width) that FOP 0.20.5 made, namely interpreting the value of
these properties as the dimensions of the image itself instead of
taking them to be the dimensions of the image's surrounding box.
Looking at the related code in the RTF library, it seems the 'height'
and 'width' of the external-graphic are interpreted as 'desired
height' and 'desired width', which is wrong if neither content-height
nor content-width were specified as 'scale-to-fit'. One can define an
external-graphic with height=10cm and still have the content take
up only 3cm.
Roughly, it seems line 952 in the RTFHandler:
newGraphic.setWidth(eg.getWidth().getValue() / 1000f + pt);
is too simplistic, and should at least become something like:
if (eg.getWidth().getEnum() != Constants.EN_AUTO) {
if (eg.getContentWidth().getEnum() == Constants.EN_SCALE_TO_FIT) {
newGraphic.setWidth(eg.getWidth().getValue() / 1000f + pt);
} ...
...
}
So, only if width is not specified as auto *and* content-width is
specified as scale-to-fit (or is of length equal to the non-auto
width) does the external-graphic's width become the desired width for
the image.
If, for instance, width=auto *and* content-width=auto, the
following could be used (instrinsic width of the image):
newGraphic.setWidth(100%);
I don't think it's all that difficult to tweak the RTFHandler into
handling these properties correctly, but then again, the question can
be asked whether it's all worth it. If the RTF renderer is going to
switch to the default image lib wrappers anyway, this effort would
perhaps be completely in vain.
Anyone?
Cheers,
Andreas
Re: Why is / is valid line breaking char in FOP?
Manuel Mall wrote: While investigating if we could use the standard java.text.BreakIterator to determine line break points I noticed that FOP uses in addition to space, zero width space, hyphen also the forward slash as a valid line breaking character. The Java BreakIterator does not recognize slash as a line breaking char (nor FWIW does MS Word). What is the background to FOP allowing this? Is this consistent with normal user expectations or is this specific to type setting environments / Tex / Knuth? The BreakIterator class is supposed to implement the Unicode TR14 standard annex http://www.unicode.org/reports/tr14/ The slash U+002F aka SOLIDUS is assigned a line breaking property value SY (Symbols Allowing Breaks) http://www.unicode.org/Public/UNIDATA/LineBreak.txt which means prevent a break before, and allow a break after. I suspect this is a recent change in Unicode, not implemented yet by your JDK release. BTW first breaking the text using whitespace, then applying the BreakIterator is unwise, because white space is significant for TR14 line breaking. Unfortunately, combining whitespace normalization, line break detection and word parsing (for hyphenation) in a single pass is unwieldy if BreakIterator is used, that's why I tried to implement it differently some time ago http://people.apache.org/~pietsch/linebreak.tar.gz J.Pietschmann
FOP Trunk documentation and release preparations
I've just committed the FOP Trunk documentation. I hope I got more or less everything. I'm sure there are a few details and typos in there. Reviewers please fix the things you find directly. I'm going to publish the website tomorrow. Sorry if I haven't been very responsive to everything the last few days. I wanted to get this off my table. I originally hoped I could push the release this week, but it'll have to wait. Next week, I'll be away but I might have enough time during that week to do a few things off-line. The biggest issue I currently see is the showstopper (ArrayIndexOutOfBounds) in table layout. I keep stumbling over that one so it seems this has to be fixed. I'll update the release plan tomorrow so we see where we stand. Good night :-) Jeremias Maerki
Re: svn commit: r328381 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: area/inline/ layoutmgr/inline/ render/ render/pdf/ render/xml/
On Tue, 25 Oct 2005 11:14 pm, [EMAIL PROTECTED] wrote: Author: lfurini Date: Tue Oct 25 08:14:10 2005 New Revision: 328381 URL: http://svn.apache.org/viewcvs?rev=328381view=rev Log: Fix for bug 36238 (at least in the PDFRenderer) The text is split into WordAreas and SpaceAreas: the latters (when the font is multibyte) are not affected by the Tw operator, so they are shifted in the inline progression dimension instead. The behaviour of the other renderers should be the same as before this change. Luca, I have a question on this. You break in TextArea the text into words based on CharUtilities.isAnySpace. Is this guaranteed to be consistent with the breaking and adjustment calculations in TextLayoutManager? I am concerned we may be using different rules for word breaking in different places. Somehow it doesn't feel right to me that TextLayoutManager does all the breaking and calculations and then we give the whole chunk to TextArea and it breaks it again using a possibly different algorithm but still using the adjustment value calculated by TextLayoutManager. May be I am too picky here or misunderstand something - sorry. Cheers Manuel
DO NOT REPLY [Bug 37236] - Fix gradients and patterns
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=37236. 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=37236 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #16799|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2005-10-26 02:19 --- Created an attachment (id=16810) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16810action=view) Update to gradient transform fix, passes all junit tests. This replaces the first patch (it has the imporant bits of the second patch commented out as well). This eliminates the concatenations list, but resets the Data transform after each push. When the PDFRenderer want's to rebuild state it just uses the transforms from the individual data elements (rather than all of the concatenations). This appears to pass all of the JUnit tests but since this is the first time I've tried to run them it's a bit hard to know what this really means (is the PDF output checked for example? Is there PDF output?). -- 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: White space handling Wiki page
Andreas, firstly a great thanks for looking at this. I am not going to comment on your comments right now but there is probably an important clarification required: All my interpretations of the spec with respect to white space handling are based on the 1.1WD not the 1.0 spec. The WG has already confirmed that the description of white space handling in 1.0 is flawed and has rewritten that part in 1.1. As I mentioned before I believe their intention was not to change the behaviour they wanted to achieve between 1.0 and 1.1 but to document it more correctly. Therefore I think it is correct and advisable to refer to 1.1 in this case. Could you please review your comments under this aspect as I believe that would clarify why I refer to line breaking vs linefeed, glyph areas vs fo's, etc. below. Which are some of the items you questioned. Manuel On Wed, 26 Oct 2005 06:22 am, Andreas L Delmelle wrote: On Oct 25, 2005, at 10:57, Manuel Mall wrote: Hi Manuel, I haven't got any technical comments to the issues raised on the Wiki page. Is this 'too hard' or 'too boring' or 'too messy' or what? All three, and more :-P Nah, seriously now, trying to comment in on the thread from last week: On Oct 19, 2005, at 03:45, Manuel Mall wrote: On Wed, 19 Oct 2005 05:44 am, Jeremias Maerki wrote: You place the white-space-treatment after the white-space-collapse but I think it is clear that the latter comes last (during area tree construction =after line breaking vs. during line-building and inline-building =before line-breaking). Yes I agree that this is a critical interpretation issue and I expected that part of the algorithm to be controversial. The problem is that in the description of value true for the white-space-collapse property it clearly refers to the fo tree and fo:character siblings in the tree. That was further clarified by an e-mail on the xsl editor list http://lists.w3.org/Archives/Public/xsl-editors/2002OctDec/0004. Once we have done line-building the fo tree (at fo:character level) is largely gone, we have now glyph areas which could have been merged, ligatures combined, etc.. That means referring at this stage back to fo:character siblings in the fo tree seems lets say unusual. Correction: the FO tree isn't 'gone' until layout for the page- sequence is finished. Only at that time are all the FObjs released. It may seem unusual to refer back to fo:character siblings, but that doesn't mean it's wrong. The corresponding FObj is still available to us at that point... The fact that we are dealing with glyph areas and not fo:character elements in line-building / area tree construction is further emphasised by the description of the handling for the white-space-treatment property. It is all defined in terms of glyph areas not fo:characters. Errm... I seem to be missing something, or aren't you talking about the XSL-FO Rec here? I can't find any reference to the term 'glyph' or 'glyph area' in the description of white-space-treatment. Many references to 'character flow object' and 'XML whitespace' though. (XSL 1.0) The passage about line-building (4.7.2) indeed talks about glyph areas, but only seems to mention suppress-at-line-break (a property which, incidentally, only applies to fo:character objects). Besides, the question that needs to be posed when handling white- space-collapse is: Should this whitespace character generate an area or not? The description in the Rec (XSL 1.0 -- 7.15.12) IMO clearly indicates that no layout information is needed to answer the above question, as it depends solely upon the character itself, the preceding and the following character. Further to this it doesn't make sense to me to collapse white space after line breaking as is implied by your interpretation because the amount of white space does contribute to the line breaking decisions. If we remove white space after line breaking we would IMO get sub optimal line breaks. In summary I think white space must be collapsed before or at least during line breaking but not after. 100% agreed. I wouldn't place it after line breaking either. It seems like a decision that can (and should?) be made *during* layout: Should this whitespace character generate an element or not? If it generates an element, it will also --if appropriate-- trigger the generation of an area. Another related issue is the description of collapsing white space around a linefeed in the spec under white-space-collapse. The spec is very specific and refers to U+000A (linefeed) fo:character siblings in the fo tree. No, it talks about 'character flow objects', which makes me wonder... Are all characters to be considered 'character flow objects' or only those that were specified using fo:character? Not that it would make a big difference, I think. This is obviously very different to removing white space around a line break generated
