search

GoogleCodeArchive / piccolo2d

Automatically exported from code.google.com/p/piccolo2d
0 stars 0 forks source link

Printing nested Nodes with PPath as border as PDF will result in different offsets #174

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. create a node on a canvas with scale 0.2
2. create a child PPath of that node that is a frame for a square give ppath a 
small scale like 
0.001
3. fill this square by adding a PNode as child to the PPath
4. print the topmost node with .print(); using a PDF printer

hmm anyone get this? I provide sample code below

What is the expected output? What do you see instead?
-The smallest Node  and its PPath wont match anymore

What version of the product are you using? On what operating system?
-Piccolo 1.2.1  on OSX 10.6

Please provide any additional information below.

here is code that reproduces this problem:

public class PiccoloPrintBug extends PFrame {
    public static void main(String[] args) {
        // frame
        PiccoloPrintBug myFrame = new PiccoloPrintBug();
        myFrame.setSize(300, 300);

        // first node
        PNode firstNode = new PNode();
        firstNode.setBounds(50, 50, 100, 100);
        firstNode.setPaint(Color.green);
        firstNode.setScale(0.02);
        myFrame.getCanvas().getLayer().addChild(firstNode);

        // PPath
        PPath ppath = new PPath();
        ppath.setBounds(0, 0, 100, 100);
        ppath.setPathTo(ppath.getBounds().getBounds());
        ppath.setPaint(null);
        ppath.setStrokePaint(Color.red);
        ppath.setStroke(new BasicStroke((float) 3.5, BasicStroke.CAP_ROUND,
                BasicStroke.JOIN_BEVEL));
        // set a small scale here
        ppath.setScale(0.01);
        // PNode filling the Path
        PNode pNode = new PNode();
        pNode.setBounds(0, 0, 100, 100);
        pNode.setPaint(Color.BLUE);

        ppath.addChild(pNode);
        firstNode.addChild(ppath);

        firstNode.print();

    }

}

Original issue reported on code.google.com by HenningS...@gmail.com on 3 Apr 2010 at 3:02

Attachments:

GoogleCodeExporter commented 9 years ago 
Printing has been improved since version 1.2.1.  Could you try with the new 
version
1.3 release and let us know?

http://code.google.com/p/piccolo2d/downloads/list?can=2&q=%221.3+binary%22&colsp
ec=Filename+Summary+Uploaded+Size+DownloadCount

Original comment by heue...@gmail.com on 3 Apr 2010 at 6:16

GoogleCodeExporter commented 9 years ago 
Ah sorry that I didn't try that in first place, with the 1.3 maven dependency i 
get the same error/behavior

Original comment by HenningS...@gmail.com on 3 Apr 2010 at 8:22

GoogleCodeExporter commented 9 years ago 
I'm thinking this is caused by a rounding error. Even if you take printing out 
of the
equation, just zooming into the PPath causes it to jitter considerably. The blue
square on the other hand seems quite stable.

Internally PPath uses Java2D's Floating point precision shapes, so this kind of 
makes
sense.

I don't think this is a printing bug as much as it is a request for higher 
precision
graphics primitives?

Any one else agree?

Original comment by allain.lalonde on 4 Apr 2010 at 1:21

GoogleCodeExporter commented 9 years ago

Original comment by heue...@gmail.com on 27 Aug 2010 at 4:17

GoogleCodeExporter commented 9 years ago 
I can get this bad behavior on Mac OS + straight up Java2D without Piccolo2D at 
play. Even if I use double-precision Path2D objects. (See attached file--I'm 
roughly mimicking the Java2D calls that Piccolo2D issues in the PiccoloPrintBug 
example above.)

On Windows, the red path draws at the same position as the blue fill. On Mac 
OS, the path and fill diverge increasingly for smaller and smaller scaling 
values:

        final Rectangle2D rect = new Rectangle2D.Double(0, 0, 200, 200);
        final AffineTransform xform = new AffineTransform(0.001, 0, 0, 0.001, 0, 0);

        // use the same path to fill and stroke -- still, they diverge
        Path2D.Double path = new Path2D.Double();
        path.append(rect, false);

        // transform for printing
        g2.transform(xform);

        // draw the path -- stroke size doesn't seem to matter, use 1
        g2.setStroke(new BasicStroke(1f, BasicStroke.CAP_ROUND, BasicStroke.JOIN_MITER));
        g2.setColor(Color.red);
        g2.draw(path);

        // draw the rectangle
        g2.setColor(Color.blue);
        g2.fill(path);

I conclude that this is a Mac OS Java issue with drawing paths to a print 
Graphics at small scale. I'm thinking there's much we can do about it, but take 
a look at my example and comment.

Original comment by atdi...@gmail.com on 1 Mar 2011 at 4:53

Attachments: