[Bug 40676] [PATCH] png graphics are expanded/uncompressed in pdf causing massive file size increase

2012-06-17 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=40676

--- Comment #16 from Luis Bernardo lmpmberna...@gmail.com ---
Created attachment 28950
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=28950action=edit
patch for documentation

I was not aware the web pages content was part of the source too... The patch
updates the documentation.

-- 
You are receiving this mail because:
You are the assignee for the bug.


Bug report for Fop [2012/06/17]

2012-06-17 Thread bugzilla
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|17369|New|Nor|2003-02-25|Footnote duplication  |
|17380|New|Nor|2003-02-25|Batik Component will not recognize fe SVG elem|
|17921|New|Nor|2003-03-12|Kerning is broken for standard fonts  |
|18801|New|Nor|2003-04-08|[PATCH] visibility property is not implemented  |
|19228|New|Nor|2003-04-22|[PATCH] Child LayoutContext is null in certain cir|
|19695|New|Enh|2003-05-06|[PATCH] Allow fox:destination as child of fox:outl|
|20280|New|Enh|2003-05-27|text-align and text-align-last only partially impl|
|20407|New|Enh|2003-06-02|[PATCH] Configure image caching using the configur|
|21265|Inf|Nor|2003-07-02|referencing a custom font (TTF or Adobe Type 1) fo|
|21905|New|Nor|2003-07-26|large list-item-label bleeds into following block |
|21982|New|Nor|2003-07-30|NullPointer Exception in LazyFont with embedded fo|
|22450|New|Nor|2003-08-15|Unterminated iteration in JPEGReader class|
|24148|New|Nor|2003-10-27|Kerning upsets text-align=end   |
|24378|New|Nor|2003-11-04|Minor problem in sample code for embedding|
|24663|New|Nor|2003-11-12|fo:block space-after property needs fixing|
|25022|New|Nor|2003-11-26|XSL-FO to PCL : images not included   |
|25341|New|Nor|2003-12-08|percentage resolution not being recalculated on di|
|25432|New|Nor|2003-12-11|Cannot embed the User Defined Characters into the |
|26047|New|Nor|2004-01-11|Space-after value remembered and used on second do|
|26590|New|Nor|2004-02-02|last character width in winansi font is missed|
|27107|New|Nor|2004-02-20|TTF Reader fails  |
|27727|New|Nor|2004-03-17|problem displaying Japanese fonts in PDF. |
|27890|New|Min|2004-03-24|fop.sh doesn't set exit status|
|29632|New|Nor|2004-06-17|Rendered reads fonts from disk everytime it render|
|30006|New|Nor|2004-07-09|eps doesn't show up in recent GhostScript versions|
|30214|New|Nor|2004-07-20|PSGraphics2D.drawImage incorrect matrix generated |
|31039|New|Nor|2004-09-03|URL in basic-link is scrambled by encryption  |
|31225|New|Nor|2004-09-14|Need embedded page sequence functionality |
|31301|New|Nor|2004-09-19|FOP limitation-Summary of columns value at Table F|
|31674|New|Enh|2004-10-12|Allow Print Renderer to select Printer and Tray.  |
|32054|New|Enh|2004-11-04|Pluggable area creation: AreaFactory  |
|32970|New|Nor|2005-01-06|incorrect elision of word space in czech text |
|33174|New|Nor|2005-01-20|An unrecognized token'NaN' was found when opening |
|35500|New|Nor|2005-06-24|Missing .close() call on stream opened for JPEG im|
|35939|New|Nor|2005-07-30|[PATCH] Port of 0.20.5 Driver.java class  |
|36011|New|Nor|2005-08-04|Setting word-spacing on justified blocks removes j|
|36238|New|Nor|2005-08-18|text-align=justify doesn't work on custom fonts |
|36395|New|Nor|2005-08-27|Common Border and Background Properties not suppor|
|36408|Inf|Min|2005-08-29|FOP hyphenation splits consecutive digits onto sep|
|36533|Inf|Nor|2005-09-07|Incorrect ipd and twsadjust settings  |
|36977|New|Nor|2005-10-09|[PATCH] TextLayoutManager CJK line break  |
|37114|New|Min|2005-10-17|No error message on illegal/unknown values on a pr|
|37136|Inf|Nor|2005-10-18|external-graphic dimensions and rendering |
|37236|New|Nor|2005-10-25|[PATCH] Fix gradients and patterns|
|37305|New|Nor|2005-10-30|Added deviceDPI to PDFDocumentGraphics2D  |
|37579|New|Nor|2005-11-21|footnotes within tables and listsl get lost   |
|38121|New|Nor|2006-01-04|border-separation disturbs table layout   |
|38244|New|Nor|2006-01-12|table-column and number-columns-spanned (prepatch)|
|38862|Inf|Nor|2006-03-06|No ImageReader for this type of image |
|39034|New|Nor|2006-03-20|page-number-citation : the text after overlaps the|
|39118|New|Nor|2006-03-27|[PATCH] Handling of page-number-citation-last |

[Bug 53431] New: [PATCH] SVG line dash pattern wrong in PDF

2012-06-17 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=53431

  Priority: P2
Bug ID: 53431
  Assignee: fop-dev@xmlgraphics.apache.org
   Summary: [PATCH] SVG line dash pattern wrong in PDF
  Severity: minor
Classification: Unclassified
OS: All
  Reporter: lmpmberna...@gmail.com
  Hardware: All
Status: NEW
   Version: all
 Component: pdf
   Product: Fop

Created attachment 28951
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=28951action=edit
patch

This issue is discussed in a recent fop-dev thread:
http://marc.info/?l=fop-devm=133817089626596w=2.

In simple terms, the following SVG element with two paths is rendered wrong in
PDF (but not in PS). The second line appears dashed when it should not be. If
the paths are flipped the rendering is correct. 

svg xmlns=http://www.w3.org/2000/svg; version=1.1 overflow=auto
path d=M 0  0 L 100  0 fill=white stroke=black stroke-width=1
stroke-dasharray=5/
path d=M 0 10 L 100 10 fill=white stroke=red stroke-width=3/
/svg

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 53431] [PATCH] SVG line dash pattern wrong in PDF

2012-06-17 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=53431

--- Comment #1 from Luis Bernardo lmpmberna...@gmail.com ---
Created attachment 28952
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=28952action=edit
source example to test bug fix

the attached file contains a test FO and SVG file, and the PDF output before
and after the fix.

-- 
You are receiving this mail because:
You are the assignee for the bug.


Re: Wrong SVG path rendering caused by overflow attribute

2012-06-17 Thread Luis Bernardo


I opened a bugzilla issue (with a fix) here: 
https://issues.apache.org/bugzilla/show_bug.cgi?id=53431


A possible workaround that does not require a fix is to place the SVG 
paths with no dasharrays at the top (i.e., before any dashed line).


On 6/13/12 12:43 AM, Luis Bernardo wrote:


This is a good investigation but I think it is not the final answer. 
If instead of generating PDF we generate PS the output is correct, and 
the same convertOverflow() method from Batik is called. Hence, I think 
there is a bug in FOP (in the rendering of the PDF), not in Batik.


On 6/1/12 3:57 PM, Robert Meyer wrote:

Hi,

I have spent a bit of time investigating this issue and found that 
the cause stems from a line of code in Batik. When the composite 
graphic node is initially created it uses the following to determine 
whether or not to create a clip associated with the object:


Class: org.apache.batik.bridge.CSSUtilities;
==
/**
 * Returns true if the 'overflow' property indicates that an
 * additional clip is required, false otherwise. An additional
 * clip is needed if the 'overflow' property is 'scroll' or
 * 'hidden'.
 *
 * @param e the element with the 'overflow' property
 */
public static boolean convertOverflow(Element e) {
Value v = getComputedStyle(e, SVGCSSEngine.OVERFLOW_INDEX);
String s = v.getStringValue();
return (s.charAt(0) == 'h') || (s.charAt(0) == 's');
}
==

As can be seen, because 'auto' and 'visible' do not match the two 
characters in the method, the clip is left as null. Because of this, 
much (much!) further down the line in FOP, a check is made and 
because there is no clip the graphics state is left as it is (dashed) 
and the line is drawn:


Class: org.apache.fop.svg.PDFGraphics2D.java:610
==
Shape imclip = getClip();
boolean newClip = paintingState.checkClip(imclip);
boolean newTransform = paintingState.checkTransform(trans)
 !trans.isIdentity();

**if (newClip || newTransform) {
saveGraphicsState();
if (newTransform) {
concatMatrix(tranvals);
}
if (newClip) {
writeClip(imclip);
}
}
==

You'll notice that in the comment for the convertOverflow method, it 
states that an additional clip is required for scroll or hidden, but 
it is clearly not working correctly for anything except those two. It 
might therefore be worth posting a bug or asking someone on their 
mailing list to follow up and check to see if that method is doing 
what it is supposed to.


Best Regards,

Robert Meyer

 Date: Tue, 29 May 2012 00:48:44 +0100
 From: lmpmberna...@gmail.com
 To: fop-dev@xmlgraphics.apache.org
 Subject: Re: Wrong SVG path rendering caused by overflow attribute


 Thanks for the excellent test case! I will investigate if no else 
does it.


 Note: incidentally your example does not run in fop-trunk due to a
 regression bug with formatting of doubles.

 On 5/28/12 3:04 AM, Jan Hilberath wrote:
  Hello,
 
  I found that depending on the value of the overflow attribute, the
  stroke of path elements may be rendered wrong.
 
  Having defined multiple paths, setting one of them to be dashed with
  stroke-dasharray causes subsequent paths to be dashed too, if the
  overflow attribute is set to auto or visible.
 
  It seems to only happen when using the InputHandler.renderTo() 
method.

  I tried the following ways to render the SVG:
 
  1) InputHandler.renderTo()
  Draws the paths incorrectly, i.e. subsequent paths have dashed 
stroke

  when auto or visible is used.
 
  2) PDFTranscoder.transcode()
  Renders correctly.
 
  3) Batik Squiggle
  Renders correctly.
 
  Versions used:
 
  batik 1.7
  fop 1.0
  xmlgraphics-commons 1.4
 
  A sample maven project that demonstrates the issue is available here:
 
  http://www.hilberath.de/tmp/fop/svg_test.zip
 
  I would appreciate if someone could have a look at this.
 
  Thank you,
 
  Jan