You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-commits@xmlgraphics.apache.org by ac...@apache.org on 2007/12/12 13:24:16 UTC
svn commit: r603590 [1/5] - in /xmlgraphics/fop/trunk: lib/
src/java/org/apache/fop/render/afp/ src/java/org/apache/fop/render/afp/modca/
src/java/org/apache/fop/render/afp/modca/goca/
src/java/org/apache/fop/render/ps/
Author: acumiskey
Date: Wed Dec 12 04:24:10 2007
New Revision: 603590
URL: http://svn.apache.org/viewvc?rev=603590&view=rev
Log:
* Added an SVG handler and Graphics2D implementation for AFP which injects AFP GOCA structured fields into the AFPDataStream.
* Fixed many checkstyle problems.
* Updated xmlgraphics-commons-1.3svn.jar to include changes to TextHandler
Added:
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPGraphics2D.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPGraphicsConfiguration.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPGraphicsDevice.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPInfo.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPPageFonts.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPState.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPTextElementBridge.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPTextHandler.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPTextPainter.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/AbstractDataObject.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/AbstractStructuredAFPObject.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/GraphicsDataDescriptor.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/GraphicsObject.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/PreparedAFPObject.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/AbstractGraphicsContainer.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/AbstractGraphicsCoord.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/AbstractPreparedAFPObject.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/GraphicsArea.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/GraphicsBox.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/GraphicsChainedSegment.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/GraphicsData.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/GraphicsFillet.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/GraphicsFullArc.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/GraphicsImageBegin.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/GraphicsImageData.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/GraphicsImageEnd.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/GraphicsLine.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/GraphicsSetArcParameters.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/GraphicsSetCharacterSet.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/GraphicsSetCurrentPosition.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/GraphicsSetLineType.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/GraphicsSetLineWidth.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/GraphicsSetPatternSymbol.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/GraphicsSetProcessColor.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/goca/GraphicsString.java
Modified:
xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.3svn.jar
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPRenderer.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPRendererConfigurator.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPRendererContextConstants.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPSVGHandler.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/AFPDataStream.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/AbstractAFPObject.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/AbstractDescriptor.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/AbstractNamedAFPObject.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/AbstractPageObject.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/ActiveEnvironmentGroup.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/ImageContent.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/ImageDataDescriptor.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/ImageObject.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/ImageSegment.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/ObjectAreaDescriptor.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/ObjectAreaPosition.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/ObjectEnvironmentGroup.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/PageDescriptor.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/PageObject.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/PresentationTextData.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/PresentationTextDescriptor.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/PresentationTextObject.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/modca/TagLogicalElementBean.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/ps/AbstractPSTranscoder.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/ps/NativeTextHandler.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/ps/PSTextPainter.java
Modified: xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.3svn.jar
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.3svn.jar?rev=603590&r1=603589&r2=603590&view=diff
==============================================================================
Binary files - no diff available.
Added: xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPGraphics2D.java
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPGraphics2D.java?rev=603590&view=auto
==============================================================================
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPGraphics2D.java (added)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPGraphics2D.java Wed Dec 12 04:24:10 2007
@@ -0,0 +1,501 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+/* $Id: $ */
+
+package org.apache.fop.render.afp;
+
+import java.awt.BasicStroke;
+import java.awt.Color;
+import java.awt.Font;
+import java.awt.FontMetrics;
+import java.awt.Graphics;
+import java.awt.GraphicsConfiguration;
+import java.awt.Image;
+import java.awt.Shape;
+import java.awt.Stroke;
+import java.awt.geom.AffineTransform;
+import java.awt.geom.Ellipse2D;
+import java.awt.geom.GeneralPath;
+import java.awt.geom.Line2D;
+import java.awt.geom.PathIterator;
+import java.awt.geom.Rectangle2D;
+import java.awt.image.BufferedImage;
+import java.awt.image.ImageObserver;
+import java.awt.image.RenderedImage;
+import java.awt.image.renderable.RenderableImage;
+import java.io.IOException;
+
+import org.apache.batik.ext.awt.geom.ExtendedGeneralPath;
+import org.apache.commons.io.output.ByteArrayOutputStream;
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+import org.apache.fop.render.afp.modca.AFPDataStream;
+import org.apache.fop.render.afp.modca.GraphicsObject;
+import org.apache.fop.render.afp.modca.ImageObject;
+import org.apache.fop.render.afp.modca.goca.GraphicsSetLineType;
+import org.apache.xmlgraphics.java2d.AbstractGraphics2D;
+import org.apache.xmlgraphics.java2d.GraphicContext;
+import org.apache.xmlgraphics.java2d.StrokingTextHandler;
+import org.apache.xmlgraphics.java2d.TextHandler;
+
+/**
+ * This is a concrete implementation of <tt>AbstractGraphics2D</tt> (and
+ * therefore of <tt>Graphics2D</tt>) which is able to generate GOCA byte
+ * codes.
+ *
+ * @see org.apache.xmlgraphics.java2d.AbstractGraphics2D
+ */
+public class AFPGraphics2D extends AbstractGraphics2D {
+
+ private static final Log log = LogFactory.getLog(AFPGraphics2D.class);
+
+ private GraphicsObject graphicsObj = null;
+
+ /** Fallback text handler */
+ protected TextHandler fallbackTextHandler = new StrokingTextHandler(this);
+
+ /** Custom text handler */
+ protected TextHandler customTextHandler = null;
+
+ /** AFP info */
+ private AFPInfo afpInfo = null;
+
+ /** Current AFP state */
+ private AFPState afpState = null;
+
+ /**
+ * @param textAsShapes
+ * if true, all text is turned into shapes in the convertion. No
+ * text is output.
+ *
+ */
+ public AFPGraphics2D(boolean textAsShapes) {
+ super(textAsShapes);
+ }
+
+ /**
+ * Creates a new AbstractGraphics2D from an existing instance.
+ *
+ * @param g
+ * the AbstractGraphics2D whose properties should be copied
+ */
+ public AFPGraphics2D(AFPGraphics2D g) {
+ super(g);
+ }
+
+ /**
+ * Sets the AFPInfo
+ *
+ * @param info
+ * the AFP Info to use
+ */
+ public void setAFPInfo(AFPInfo info) {
+ this.afpInfo = info;
+ this.afpState = info.getState();
+ }
+
+ /**
+ * Gets the AFPInfo
+ *
+ * @return the AFPInfo
+ */
+ public AFPInfo getAFPInfo() {
+ return this.afpInfo;
+ }
+
+ /**
+ * Sets the GraphicContext
+ *
+ * @param gc
+ * GraphicContext to use
+ */
+ public void setGraphicContext(GraphicContext gc) {
+ this.gc = gc;
+ }
+
+ /**
+ * Apply the stroke to the AFP graphics object.
+ * This takes the java stroke and outputs the appropriate settings
+ * to the AFP graphics object so that the stroke attributes are handled.
+ *
+ * @param stroke the java stroke
+ */
+ protected void applyStroke(Stroke stroke) {
+ if (stroke instanceof BasicStroke) {
+ BasicStroke basicStroke = (BasicStroke) stroke;
+ float lineWidth = basicStroke.getLineWidth();
+ if (afpState.setLineWidth(lineWidth)) {
+ getGraphicsObject().setLineWidth(Math.round(lineWidth * 2));
+ }
+ // note: this is an approximation at best!
+ float[] dashArray = basicStroke.getDashArray();
+ if (afpState.setDashArray(dashArray)) {
+ byte type = GraphicsSetLineType.DEFAULT; // normally SOLID
+ if (dashArray != null) {
+ type = GraphicsSetLineType.DOTTED; // default to DOTTED
+ // float offset = basicStroke.getDashPhase();
+ if (dashArray.length == 2) {
+ if (dashArray[0] < dashArray[1]) {
+ type = GraphicsSetLineType.SHORT_DASHED;
+ } else if (dashArray[0] > dashArray[1]) {
+ type = GraphicsSetLineType.LONG_DASHED;
+ }
+ } else if (dashArray.length == 4) {
+ if (dashArray[0] > dashArray[1]
+ && dashArray[2] < dashArray[3]) {
+ type = GraphicsSetLineType.DASH_DOT;
+ } else if (dashArray[0] < dashArray[1]
+ && dashArray[2] < dashArray[3]) {
+ type = GraphicsSetLineType.DOUBLE_DOTTED;
+ }
+ } else if (dashArray.length == 6) {
+ if (dashArray[0] > dashArray[1]
+ && dashArray[2] < dashArray[3]
+ && dashArray[4] < dashArray[5]) {
+ type = GraphicsSetLineType.DASH_DOUBLE_DOTTED;
+ }
+ }
+ }
+ getGraphicsObject().setLineType(type);
+ }
+ } else {
+ log.warn("Unsupported Stroke: " + stroke.getClass().getName());
+ }
+ }
+
+ /**
+ * Handle the Batik drawing event
+ *
+ * @param shape
+ * the shape to draw
+ * @param fill
+ * true if the shape is to be drawn filled
+ */
+ private void doDrawing(Shape shape, boolean fill) {
+ getGraphicsObject();
+ if (!fill) {
+ graphicsObj.newSegment();
+ }
+ Color col = getColor();
+ if (afpState.setColor(col)) {
+ graphicsObj.setColor(col);
+ }
+
+ applyStroke(getStroke());
+
+ if (fill) {
+ graphicsObj.beginArea();
+ }
+ AffineTransform trans = super.getTransform();
+ PathIterator iter = shape.getPathIterator(trans);
+ double[] vals = new double[6];
+ int[] coords = null;
+ if (shape instanceof GeneralPath || shape instanceof ExtendedGeneralPath) {
+ // graphics segment opening coordinates (x,y)
+ int[] openingCoords = new int[2];
+ // current position coordinates (x,y)
+ int[] currCoords = new int[2];
+ NEXT_ITER: while (!iter.isDone()) {
+ // round the coordinate values and combine with current position
+ // coordinates
+ int type = iter.currentSegment(vals);
+ if (type == PathIterator.SEG_MOVETO) {
+ log.debug("SEG_MOVETO");
+ openingCoords[0] = currCoords[0] = (int)Math.round(vals[0]);
+ openingCoords[1] = currCoords[1] = (int)Math.round(vals[1]);
+ } else {
+ int numCoords;
+ if (type == PathIterator.SEG_LINETO) {
+ log.debug("SEG_LINETO");
+ numCoords = 2;
+ } else if (type == PathIterator.SEG_QUADTO) {
+ log.debug("SEG_QUADTO");
+ numCoords = 4;
+ } else if (type == PathIterator.SEG_CUBICTO) {
+ log.debug("SEG_CUBICTO");
+ numCoords = 6;
+ } else {
+ // close of the graphics segment
+ if (type == PathIterator.SEG_CLOSE) {
+ log.debug("SEG_CLOSE");
+ coords = new int[] {
+ coords[coords.length - 2],
+ coords[coords.length - 1],
+ openingCoords[0],
+ openingCoords[1]
+ };
+ graphicsObj.addLine(coords);
+ } else {
+ log.debug("Unrecognised path iterator type: "
+ + type);
+ }
+ iter.next();
+ continue NEXT_ITER;
+ }
+ // combine current position coordinates with new graphics
+ // segment coordinates
+ coords = new int[numCoords + 2];
+ coords[0] = currCoords[0];
+ coords[1] = currCoords[1];
+ for (int i = 0; i < numCoords; i++) {
+ coords[i + 2] = (int) Math.round(vals[i]);
+ }
+ if (type == PathIterator.SEG_LINETO) {
+ graphicsObj.addLine(coords);
+ } else if (type == PathIterator.SEG_QUADTO
+ || type == PathIterator.SEG_CUBICTO) {
+ graphicsObj.addFillet(coords);
+ }
+ // update current position coordinates
+ currCoords[0] = coords[coords.length - 2];
+ currCoords[1] = coords[coords.length - 1];
+ }
+ iter.next();
+ }
+ } else if (shape instanceof Line2D) {
+ iter.currentSegment(vals);
+ coords = new int[4];
+ coords[0] = (int) Math.round(vals[0]);
+ coords[1] = (int) Math.round(vals[1]);
+ iter.next();
+ iter.currentSegment(vals);
+ coords[2] = (int) Math.round(vals[0]);
+ coords[3] = (int) Math.round(vals[1]);
+ graphicsObj.addLine(coords);
+ } else if (shape instanceof Rectangle2D) {
+ iter.currentSegment(vals);
+ coords = new int[4];
+ coords[2] = (int) Math.round(vals[0]);
+ coords[3] = (int) Math.round(vals[1]);
+ iter.next();
+ iter.next();
+ iter.currentSegment(vals);
+ coords[0] = (int) Math.round(vals[0]);
+ coords[1] = (int) Math.round(vals[1]);
+ graphicsObj.addBox(coords);
+ } else if (shape instanceof Ellipse2D) {
+ Ellipse2D elip = (Ellipse2D) shape;
+ final double factor = afpInfo.resolution / 100f;
+ graphicsObj.setArcParams(
+ (int)Math.round(elip.getWidth() * factor),
+ (int)Math.round(elip.getHeight() * factor),
+ 0,
+ 0
+ );
+ trans.transform(
+ new double[] {elip.getCenterX(), elip.getCenterY()}, 0,
+ vals, 0, 1);
+ final int mh = 1;
+ final int mhr = 0;
+ graphicsObj.addFullArc(
+ (int)Math.round(vals[0]),
+ (int)Math.round(vals[1]),
+ mh,
+ mhr
+ );
+ } else {
+ log.error("Unrecognised shape: " + shape);
+ }
+ if (fill) {
+ graphicsObj.endArea();
+ }
+ }
+
+ /**
+ * {@inheritDoc}
+ */
+ public void draw(Shape shape) {
+ log.debug("draw() shape=" + shape);
+ doDrawing(shape, false);
+ }
+
+ /**
+ * {@inheritDoc}
+ */
+ public void fill(Shape shape) {
+ log.debug("fill() shape=" + shape);
+ doDrawing(shape, true);
+ }
+
+ /**
+ * Central handler for IOExceptions for this class.
+ *
+ * @param ioe
+ * IOException to handle
+ */
+ public void handleIOException(IOException ioe) {
+ // TODO Surely, there's a better way to do this.
+ ioe.printStackTrace();
+ }
+
+ /**
+ * {@inheritDoc}
+ */
+ public void drawRenderableImage(RenderableImage img, AffineTransform xform) {
+ log.debug("drawRenderableImage() NYI: img=" + img + ", xform=" + xform);
+ }
+
+ /**
+ * {@inheritDoc}
+ */
+ public void drawRenderedImage(RenderedImage img, AffineTransform xform) {
+ log.debug("drawRenderedImage() NYI: img=" + img + ", xform=" + xform);
+ }
+
+ /**
+ * {@inheritDoc}
+ */
+ public void drawString(String s, float x, float y) {
+ try {
+ if (customTextHandler != null && !textAsShapes) {
+ customTextHandler.drawString(s, x, y);
+ } else {
+ fallbackTextHandler.drawString(s, x, y);
+ }
+ } catch (IOException ioe) {
+ handleIOException(ioe);
+ }
+ }
+
+ /**
+ * {@inheritDoc}
+ */
+ public GraphicsConfiguration getDeviceConfiguration() {
+ return new AFPGraphicsConfiguration();
+ }
+
+ /**
+ * {@inheritDoc}
+ */
+ public void copyArea(int x, int y, int width, int height, int dx, int dy) {
+ log.debug("copyArea() NYI: ");
+ }
+
+ /**
+ * {@inheritDoc}
+ */
+ public Graphics create() {
+ return new AFPGraphics2D(this);
+ }
+
+ /**
+ * {@inheritDoc}
+ */
+ public void dispose() {
+ log.debug("dispose() NYI: ");
+ }
+
+ /**
+ * {@inheritDoc}
+ */
+ public boolean drawImage(Image img, int x, int y, ImageObserver observer) {
+ return drawImage(img, x, y, img.getWidth(observer), img.getHeight(observer), observer);
+ }
+
+ /**
+ * {@inheritDoc}
+ */
+ public boolean drawImage(Image img, int x, int y, int width, int height,
+ ImageObserver observer) {
+ log.debug("drawImage() img=" + img + ", x=" + x + ", y=" + y
+ + ", width=" + width + ", height=" + height + ", obs=" + observer);
+
+ int afpres = afpInfo.resolution;
+ int afpBitsPerPixel = afpInfo.bitsPerPixel;
+ int afpx = x;
+ int afpy = y;
+ int afpw = width;
+ int afph = height;
+ boolean colorImages = !afpInfo.grayscale;
+ int imageResolution = afpres;
+ if (img instanceof BufferedImage) {
+ BufferedImage bi = (BufferedImage)img;
+ ByteArrayOutputStream baout = new ByteArrayOutputStream();
+ try {
+ // Serialize image
+ AFPRenderer.writeImage(bi, baout);
+ byte[] buf = baout.toByteArray();
+
+ // Generate image
+ AFPDataStream afpDataStream = afpInfo.afpDataStream;
+ ImageObject io = afpDataStream.getImageObject(afpx, afpy, afpw,
+ afph, afpres, afpres);
+ io.setImageParameters(imageResolution, imageResolution,
+ afpw, afph);
+ if (colorImages) {
+ io.setImageIDESize((byte)24);
+ io.setImageData(buf);
+ } else {
+ AFPRenderer.convertToGrayScaleImage(io, buf, afpw, afph, afpBitsPerPixel);
+ }
+ } catch (IOException ioe) {
+ log.error("Error while serializing bitmap: " + ioe.getMessage(),
+ ioe);
+ return false;
+ }
+ return true;
+ } else {
+ log.debug("drawImage() NYI: img=" + img + ", x=" + x + ", y=" + y
+ + ", observer=" + observer);
+ }
+ return false;
+ }
+
+ /**
+ * {@inheritDoc}
+ */
+ public FontMetrics getFontMetrics(Font f) {
+ log.debug("getFontMetrics() NYI: f=" + f);
+ return null;
+ }
+
+ /**
+ * {@inheritDoc}
+ */
+ public void setXORMode(Color col) {
+ log.debug("setXORMode() NYI: col=" + col);
+ }
+
+ /**
+ * Sets a custom TextHandler implementation that is responsible for painting
+ * text. The default TextHandler paints all text as shapes. A custom
+ * implementation can implement text painting using text painting operators.
+ *
+ * @param handler
+ * the custom TextHandler implementation
+ */
+ public void setCustomTextHandler(TextHandler handler) {
+ this.customTextHandler = handler;
+ }
+
+ /**
+ * @return the GOCA graphics object
+ */
+ protected GraphicsObject getGraphicsObject() {
+ if (this.graphicsObj == null) {
+ int x = (int)Math.round((afpInfo.currentXPosition * 25.4f) / 1000);
+ int y = (int)Math.round((afpInfo.currentYPosition * 25.4f) / 1000);
+ int res = afpInfo.resolution;
+ int width = (int)Math.round((afpInfo.width * res) / 72000f);
+ int height = (int)Math.round((afpInfo.height * res) / 72000f);
+ this.graphicsObj = afpInfo.getAFPDataStream().getGraphicsObject(
+ x, y, width, height, res, res);
+ }
+ return this.graphicsObj;
+ }
+}
\ No newline at end of file
Added: xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPGraphicsConfiguration.java
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPGraphicsConfiguration.java?rev=603590&view=auto
==============================================================================
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPGraphicsConfiguration.java (added)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPGraphicsConfiguration.java Wed Dec 12 04:24:10 2007
@@ -0,0 +1,155 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+/* $Id: $ */
+
+package org.apache.fop.render.afp;
+
+import java.awt.GraphicsDevice;
+import java.awt.Rectangle;
+import java.awt.Transparency;
+import java.awt.geom.AffineTransform;
+import java.awt.image.BufferedImage;
+import java.awt.image.ColorModel;
+
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+import org.apache.fop.svg.GraphicsConfiguration;
+
+/**
+ * Our implementation of the class that returns information about
+ * roughly what we can handle and want to see (alpha for example).
+ */
+public class AFPGraphicsConfiguration extends GraphicsConfiguration {
+ // We use this to get a good colormodel..
+ private static final BufferedImage BI_WITH_ALPHA
+ = new BufferedImage(1, 1, BufferedImage.TYPE_INT_ARGB);
+ // We use this to get a good colormodel..
+ private static final BufferedImage BI_WITHOUT_ALPHA
+ = new BufferedImage(1, 1, BufferedImage.TYPE_INT_RGB);
+
+ /**
+ * Construct a buffered image with an alpha channel, unless
+ * transparencty is OPAQUE (no alpha at all).
+ *
+ * @param width the width of the image
+ * @param height the height of the image
+ * @param transparency the alpha value of the image
+ * @return the new buffered image
+ */
+ public BufferedImage createCompatibleImage(int width, int height,
+ int transparency) {
+ if (transparency == Transparency.OPAQUE) {
+ return new BufferedImage(width, height,
+ BufferedImage.TYPE_INT_RGB);
+ } else {
+ return new BufferedImage(width, height,
+ BufferedImage.TYPE_INT_ARGB);
+ }
+ }
+
+ /**
+ * Construct a buffered image with an alpha channel.
+ *
+ * @param width the width of the image
+ * @param height the height of the image
+ * @return the new buffered image
+ */
+ public BufferedImage createCompatibleImage(int width, int height) {
+ return new BufferedImage(width, height,
+ BufferedImage.TYPE_INT_ARGB);
+ }
+
+ /**
+ * TODO: This should return the page bounds in Pts,
+ * I couldn't figure out how to get this for the current
+ * page from the PDFDocument (this still works for now,
+ * but it should be fixed...).
+ *
+ * @return the bounds of the PDF document page
+ */
+ public Rectangle getBounds() {
+ return null;
+ }
+
+ /**
+ * Return a good default color model for this 'device'.
+ * @return the colour model for the configuration
+ */
+ public ColorModel getColorModel() {
+ return BI_WITH_ALPHA.getColorModel();
+ }
+
+ /**
+ * Return a good color model given <tt>transparency</tt>
+ *
+ * @param transparency the alpha value for the colour model
+ * @return the colour model for the configuration
+ */
+ public ColorModel getColorModel(int transparency) {
+ if (transparency == Transparency.OPAQUE) {
+ return BI_WITHOUT_ALPHA.getColorModel();
+ } else {
+ return BI_WITH_ALPHA.getColorModel();
+ }
+ }
+
+ private static final Log log = LogFactory.getLog(AFPGraphicsConfiguration.class);
+
+ private AffineTransform defaultTransform = null;
+ private AffineTransform normalizingTransform = null;
+ private GraphicsDevice graphicsDevice = null;
+
+ /**
+ * The default transform (1:1).
+ *
+ * @return the default transform for the configuration
+ */
+ public AffineTransform getDefaultTransform() {
+ log.debug("getDefaultTransform()");
+ if (defaultTransform == null) {
+ defaultTransform = new AffineTransform();
+ }
+ return defaultTransform;
+ }
+
+ /**
+ * The normalizing transform (1:1) (since we currently
+ * render images at 72dpi, which we might want to change
+ * in the future).
+ *
+ * @return the normalizing transform for the configuration
+ */
+ public AffineTransform getNormalizingTransform() {
+ log.debug("getNormalizingTransform()");
+ if (normalizingTransform == null) {
+ normalizingTransform = new AffineTransform(2, 0, 0, 2, 0, 0);
+ }
+ return normalizingTransform;
+ }
+
+ /**
+ * {@inheritDoc}
+ */
+ public GraphicsDevice getDevice() {
+ log.debug("getDevice()");
+ if (graphicsDevice == null) {
+ graphicsDevice = new AFPGraphicsDevice(this);
+ }
+ return graphicsDevice;
+ }
+}
Added: xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPGraphicsDevice.java
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPGraphicsDevice.java?rev=603590&view=auto
==============================================================================
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPGraphicsDevice.java (added)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPGraphicsDevice.java Wed Dec 12 04:24:10 2007
@@ -0,0 +1,80 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+/* $Id: $ */
+
+package org.apache.fop.render.afp;
+
+import java.awt.GraphicsConfiguration;
+import java.awt.GraphicsDevice;
+
+/**
+ * This implements the GraphicsDevice interface as appropriate for
+ * an AFPGraphics2D.
+ */
+public class AFPGraphicsDevice extends GraphicsDevice {
+
+ /**
+ * The Graphics Config that created us...
+ */
+ protected GraphicsConfiguration gc;
+
+ /**
+ * Create a new AF{ graphics device.
+ *
+ * @param gc The graphics configuration we should reference
+ */
+ public AFPGraphicsDevice(AFPGraphicsConfiguration gc) {
+ this.gc = gc;
+ }
+
+ /**
+ * Return an array of our one GraphicsConfig
+ *
+ * @return an array containing the one graphics configuration
+ */
+ public GraphicsConfiguration[] getConfigurations() {
+ return new GraphicsConfiguration[] {gc};
+ }
+
+ /**
+ * Return out sole GraphicsConfig.
+ *
+ * @return the graphics configuration that created this object
+ */
+ public GraphicsConfiguration getDefaultConfiguration() {
+ return this.gc;
+ }
+
+ /**
+ * Generate an IdString..
+ *
+ * @return the ID string for this device, uses toString
+ */
+ public String getIDstring() {
+ return toString();
+ }
+
+ /**
+ * Let the caller know that we are "a printer"
+ *
+ * @return the type which is always printer
+ */
+ public int getType() {
+ return GraphicsDevice.TYPE_PRINTER;
+ }
+}
Added: xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPInfo.java
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPInfo.java?rev=603590&view=auto
==============================================================================
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPInfo.java (added)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPInfo.java Wed Dec 12 04:24:10 2007
@@ -0,0 +1,120 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+/* $Id: $ */
+
+package org.apache.fop.render.afp;
+
+import org.apache.avalon.framework.configuration.Configuration;
+import org.apache.fop.fonts.FontInfo;
+import org.apache.fop.render.afp.modca.AFPDataStream;
+
+/**
+ * AFP information structure for drawing the XML document.
+ */
+public final class AFPInfo {
+ /** see WIDTH */
+ protected int width;
+ /** see HEIGHT */
+ protected int height;
+ /** see XPOS */
+ protected int currentXPosition;
+ /** see YPOS */
+ protected int currentYPosition;
+ /** see HANDLER_CONFIGURATION */
+ protected Configuration cfg;
+
+ /** see AFP_FONT_INFO */
+ protected FontInfo fontInfo;
+ /** See AFP_DATASTREAM */
+ protected AFPDataStream afpDataStream;
+ /** See AFP_STATE */
+ protected AFPState afpState;
+ /** see AFP_GRAYSCALE */
+ protected boolean grayscale;
+ /** see AFP_RESOLUTION */
+ protected int resolution;
+ /** see AFP_BITS_PER_PIXEL */
+ protected int bitsPerPixel;
+
+ /**
+ * Returns the width.
+ * @return the width
+ */
+ public int getWidth() {
+ return width;
+ }
+
+ /**
+ * Sets the width.
+ * @param width The pageWidth to set
+ */
+ public void setWidth(int width) {
+ this.width = width;
+ }
+
+ /**
+ * Returns the height.
+ * @return the height
+ */
+ public int getHeight() {
+ return height;
+ }
+
+ /**
+ * Sets the height.
+ * @param height The height to set
+ */
+ public void setHeight(int height) {
+ this.height = height;
+ }
+
+ /**
+ * @return Configuration the handler configuration
+ */
+ public Configuration getHandlerConfiguration() {
+ return this.cfg;
+ }
+
+ /**
+ * @return FontInfo the font info
+ */
+ public FontInfo getFontInfo() {
+ return this.fontInfo;
+ }
+
+ /**
+ * @return Map the current page fonts
+ */
+ public AFPState getState() {
+ return this.afpState;
+ }
+
+ /**
+ * @return AFPDataStream the afp datastream
+ */
+ public AFPDataStream getAFPDataStream() {
+ return this.afpDataStream;
+ }
+
+ /**
+ * @return true if supports color
+ */
+ public boolean isColorSupported() {
+ return !this.grayscale;
+ }
+}
\ No newline at end of file
Added: xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPPageFonts.java
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPPageFonts.java?rev=603590&view=auto
==============================================================================
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPPageFonts.java (added)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPPageFonts.java Wed Dec 12 04:24:10 2007
@@ -0,0 +1,48 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+/* $Id: $ */
+
+package org.apache.fop.render.afp;
+
+import org.apache.fop.render.afp.fonts.AFPFont;
+
+/**
+ * Holds the current page fonts
+ */
+public class AFPPageFonts extends java.util.HashMap {
+ private static final long serialVersionUID = -4991896259427109041L;
+
+ /**
+ * Registers a font on the current page and returns font attributes
+ * @param fontName the internal font name
+ * @param font the AFPFont
+ * @param fontSize the font point size
+ * @return newly registered AFPFontAttributes
+ */
+ public AFPFontAttributes registerFont(String fontName, AFPFont font, int fontSize) {
+ String pageFontKey = fontName + "_" + fontSize;
+ AFPFontAttributes afpFontAttributes = (AFPFontAttributes)super.get(pageFontKey);
+ // Add to page font mapping if not already present
+ if (afpFontAttributes == null) {
+ afpFontAttributes = new AFPFontAttributes(fontName, font, fontSize);
+ super.put(pageFontKey, afpFontAttributes);
+ afpFontAttributes.setFontReference(super.size());
+ }
+ return afpFontAttributes;
+ }
+}
\ No newline at end of file
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org
Re: AFP Renderer problems (Re: svn commit: r603590)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 15.01.2008 18:04:14 Adrian Cumiskey wrote:
> Hi Jeremias,
>
> The AFPRenderer should still work fine and produce valid AFP documents, its just source documents
> which contain embedded SVG will not be rendered correctly (but will still contain valid AFP).
Uhm, in that case you should run block-container_absolute-position_reference-orientation.xml
through the AFP renderer. No SVG and still no luck:
- IE plugin & AFP workbench are not displaying any text
- AFP Explorer is even crashing
> It
> should be fine to just update me with the details of your area tree changes and I will make the
> necessary adjustments to the AFPRenderer... that'll teach me to work from trunk.. :)
Thanks!
> Adrian.
>
> Jeremias Maerki wrote:
> > Thanks for the feedback. It's certainly cool if you can make a single
> > SVG (or other graphic) a separate resource group that can potentially be
> > reused. It's something I'd like to do for PDF at some point.
> >
> > The reason I was pinging you was that I'm working on that semantic
> > change in the area tree I was writing about last week. Since the
> > AFPRenderer is currently broken and you're working on it I will not be
> > able to adjust the AFPRenderer to that semantic change. I'll just fix
> > the other renderers and will inform you about the details. Can you then
> > do the necessary adjustments in the AFPRenderer? It won't be too hard.
> > Thanks.
> >
> > On 15.01.2008 17:25:14 Adrian Cumiskey wrote:
> >> Hi Jeremias,
> >>
> >> I have tested the AFP output with a number of applications and the AFPRenderer is at fault here.
> >> The GOCA should have been included as part of an overlay rather than just added to the current page.
> >> But in doing so would break the current way that documents are constructed by the AFP datastream.
> >>
> >> Another issue which is related to this implementation is the more general way that resources
> >> (images/graphics/fonts etc) are handled (or not). Currently the AFP renderer simply creates a new
> >> copy of the resource object with a unique name and embeds it directly in the current page. So I am
> >> looking at adding some flexibility here so that resource objects are not duplicated and are instead
> >> included and stored (keeping their original source name) within a resource group. A configurable
> >> option will also be provided so you are able to set the level at which you would like the resources
> >> to be stored (externally, print-file, document, page-group or page). When this is done I will use
> >> the this new implementation to include graphics objects correctly.
> >>
> >> Adrian.
> >>
> >> Jeremias Maerki wrote:
> >>> Adrian,
> >>>
> >>> do you have an update on this topic? It would be good to know if the IE
> >>> plug-in is at fault or the AFPRenderer.
> >>>
> >>> On 14.12.2007 15:31:19 Jeremias Maerki wrote:
> >>>> FO file is attached (to be run from the FOP root directory).
> >>>>
> >>>> Expectation: see out.pdf
> >>>> Effective output in AFP plug-in for IE: see screenshot-ie-afp.png
> >>>>
> >>>> (produced with FOP Trunk rev 604185)
> >>>>
> >>>> It could very well be that the IE plug-in has a problem here. I have no
> >>>> other viewer to check against.
> >>>>
> >>>> On 14.12.2007 14:58:39 Adrian Cumiskey wrote:
> >>>>> Jeremias Maerki wrote:
> >>>>>> I only have the IE plugin. No AFP hardware to test with. snif.
> >>>>>>
> >>>>>> Basically, it was just a:
> >>>>>> <fo:block>
> >>>>>> <fo:external-graphic src="test/resources/images/img-w-size.svg"/>
> >>>>>> </fo:block>
> >>>>>>
> >>>>>> No special configuration (i.e. the defaults). Really the simplest of
> >>>>>> possible cases and it came out wrong.
> >>>>> How did you expect it to come out? How do you think it is wrong?
> >>>>>
> >>>>> Adrian.
> >>>>
> >>>>
> >>>> Jeremias Maerki
> >>>
> >>>
> >>>
> >>> Jeremias Maerki
> >>>
> >>>
> >
> >
> >
> >
> > Jeremias Maerki
> >
> >
Jeremias Maerki
Re: AFP Renderer problems (Re: svn commit: r603590)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Resources like graphics, fonts and XMP are not really the problem here.
Graphics are still referenced by URI or embedded as foreign XML. Fonts
need to be handled by the IFHandler anyway, the fonts are only
referenced by name plus additional properties. XMP is handled the same
way as foreign XML. Some other extensions may have more impact here.
Furthermore, the renderers handle resource management themselves,
based on what they support (PDF has objects which makes it easy, PS
requires rewriting the whole PS file to factor out resources used
multiple times, Java2D doesn't do any resource optimization).
The main point I wanted to make here is differences in the fundamental
approach of the different output formats. An example:
PDF, PS and Java2D can all handle free-form transformation à la
AffineTransform (translation, free rotation, skewing). PCL, however,
only allows rotation by 90 degree steps, no scaling (you can only scale
by modifying font sizes and line widths), no skewing. If you switch from
PCL to HP/GL you can do some more but you still stay way behind the
first three formats. I'm not sure about AFP but it may have some
restrictions, too, but probably not as many as PCL.
If we did what you propose, we'd actually have to incorporate
renderer-specific code in the IFRenderer which I absolutely want to
avoid because it splits the logic between two components which doesn't
help us.
On 16.01.2008 23:13:56 Andreas L Delmelle wrote:
> On Jan 16, 2008, at 08:15, Jeremias Maerki wrote:
>
> > Hey, I don't like doing stuff twice or more times. Each output format
> > has its own specifics and there are limits to what extent
> > commonalities
> > can be extracted. For example, some formats don't support free-form
> > transformations. In PCL, it's impossible to write a Graphics2D
> > implementation that doesn't end up using bitmaps instead of native
> > commands to paint the individual elements. Actually, that fact is
> > exactly the point what's concerning me most if I think about a new
> > intermediate format which will result in a different kind of
> > abstraction
> > for the rendering components.
>
> Hmm... So it seems like it does not only depend on the renderer, but
> also on the type of resource (graphic, font, XMP metadata packet...).
> Maybe separating into an AbstractRendererResource would be an idea:
> a PDFFontResource could easily share logic with an AWTFontResource or
> AFPFontResource, or even PDFGraphicResource.
>
> Point being that their interface towards the AbstractRenderer remains
> uniform, while the behaviour can still be dedicated to one specific
> renderer.
>
> Those components/resources that apply to all types of renderers, can
> be handled in AbstractRenderer.
> AbstractRenderer could provide a generic createResource() method,
> which can be overridden or re-implemented in the specific renderer
> types to handle the renderer-specific stuff.
>
> Coming to the Intermediate Format: that document should, as you
> mentioned earlier IIRC, ideally be renderer-agnostic. So, if all is
> set up well, the resources can be embedded/referenced in the
> intermediate document as abstract <resource> nodes, with a reference
> (attribute?) to the applicable renderers. Some resources may have to
> be inserted multiple times for different renderers? So be it. The
> IFHandler should probably be made intelligent enough to ignore/
> disregard any nodes that do not apply to the current output format,
> so they get excluded real early in the game. When the document is
> ultimately rendered, the eventual renderer type will determine what
> needs to happen with the embedded resource.
>
>
> Cheers
>
> Andreas
>
Jeremias Maerki
Re: AFP Renderer problems (Re: svn commit: r603590)
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jan 17, 2008, at 09:55, Chris Bowditch wrote:
> Andreas L Delmelle wrote:
>
> <snip/>
>
>> Those components/resources that apply to all types of renderers,
>> can be handled in AbstractRenderer.
>> AbstractRenderer could provide a generic createResource() method,
>> which can be overridden or re-implemented in the specific
>> renderer types to handle the renderer-specific stuff.
>> Coming to the Intermediate Format: that document should, as you
>> mentioned earlier IIRC, ideally be renderer-agnostic. So, if all
>> is set up well, the resources can be embedded/referenced in the
>> intermediate document as abstract <resource> nodes, with a
>> reference (attribute?) to the applicable renderers. Some
>> resources may have to be inserted multiple times for different
>> renderers? So be it. The IFHandler should probably be made
>> intelligent enough to ignore/ disregard any nodes that do not
>> apply to the current output format, so they get excluded real
>> early in the game. When the document is ultimately rendered, the
>> eventual renderer type will determine what needs to happen with
>> the embedded resource.
>
> The downside to including a resource node for each possible
> renderer is the space occupied by the Intermediate Format.
Wouldn't be much, if we precisely aim at keeping them in the document
root.
> The major problem with the current IF XML is how verbose it is.
> This verbosity is what makes the performance of FO->IF->PDF so
> slow. This is the main driver for re-working the current
> implementation.
Qua processing, when the eventual IF XML is read back in, the
resource nodes that do not apply to the output format for that run
should generate only very little overhead, since we would ignore
them. If the goal is to have one and the same IF XML that can be
transparently rendered to either PDF, AFP or PCL, then including
separate resources for separate renderers may turn out to be a
necessary evil... If some renderers can be made to share resources
(or logic in handling specific resource types), all the better, but I
think Jeremias precisely hinted on that having its limits.
Cheers
Andreas
Re: AFP Renderer problems (Re: svn commit: r603590)
Posted by Chris Bowditch <bo...@hotmail.com>.
Andreas L Delmelle wrote:
<snip/>
>
> Those components/resources that apply to all types of renderers, can be
> handled in AbstractRenderer.
> AbstractRenderer could provide a generic createResource() method, which
> can be overridden or re-implemented in the specific renderer types to
> handle the renderer-specific stuff.
>
> Coming to the Intermediate Format: that document should, as you
> mentioned earlier IIRC, ideally be renderer-agnostic. So, if all is set
> up well, the resources can be embedded/referenced in the intermediate
> document as abstract <resource> nodes, with a reference (attribute?) to
> the applicable renderers. Some resources may have to be inserted
> multiple times for different renderers? So be it. The IFHandler should
> probably be made intelligent enough to ignore/ disregard any nodes that
> do not apply to the current output format, so they get excluded real
> early in the game. When the document is ultimately rendered, the
> eventual renderer type will determine what needs to happen with the
> embedded resource.
The downside to including a resource node for each possible renderer is
the space occupied by the Intermediate Format. The major problem with
the current IF XML is how verbose it is. This verbosity is what makes
the performance of FO->IF->PDF so slow. This is the main driver for
re-working the current implementation.
Chris
Re: AFP Renderer problems (Re: svn commit: r603590)
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jan 16, 2008, at 08:15, Jeremias Maerki wrote:
> Hey, I don't like doing stuff twice or more times. Each output format
> has its own specifics and there are limits to what extent
> commonalities
> can be extracted. For example, some formats don't support free-form
> transformations. In PCL, it's impossible to write a Graphics2D
> implementation that doesn't end up using bitmaps instead of native
> commands to paint the individual elements. Actually, that fact is
> exactly the point what's concerning me most if I think about a new
> intermediate format which will result in a different kind of
> abstraction
> for the rendering components.
Hmm... So it seems like it does not only depend on the renderer, but
also on the type of resource (graphic, font, XMP metadata packet...).
Maybe separating into an AbstractRendererResource would be an idea:
a PDFFontResource could easily share logic with an AWTFontResource or
AFPFontResource, or even PDFGraphicResource.
Point being that their interface towards the AbstractRenderer remains
uniform, while the behaviour can still be dedicated to one specific
renderer.
Those components/resources that apply to all types of renderers, can
be handled in AbstractRenderer.
AbstractRenderer could provide a generic createResource() method,
which can be overridden or re-implemented in the specific renderer
types to handle the renderer-specific stuff.
Coming to the Intermediate Format: that document should, as you
mentioned earlier IIRC, ideally be renderer-agnostic. So, if all is
set up well, the resources can be embedded/referenced in the
intermediate document as abstract <resource> nodes, with a reference
(attribute?) to the applicable renderers. Some resources may have to
be inserted multiple times for different renderers? So be it. The
IFHandler should probably be made intelligent enough to ignore/
disregard any nodes that do not apply to the current output format,
so they get excluded real early in the game. When the document is
ultimately rendered, the eventual renderer type will determine what
needs to happen with the embedded resource.
Cheers
Andreas
Re: AFP Renderer problems (Re: svn commit: r603590)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hey, I don't like doing stuff twice or more times. Each output format
has its own specifics and there are limits to what extent commonalities
can be extracted. For example, some formats don't support free-form
transformations. In PCL, it's impossible to write a Graphics2D
implementation that doesn't end up using bitmaps instead of native
commands to paint the individual elements. Actually, that fact is
exactly the point what's concerning me most if I think about a new
intermediate format which will result in a different kind of abstraction
for the rendering components.
On 15.01.2008 23:18:07 Andreas L Delmelle wrote:
> On Jan 15, 2008, at 17:53, Jeremias Maerki wrote:
>
> Hi guys
>
> Sorry to interrupt (currently being completely AFP-agnostic :-))
>
> > Thanks for the feedback. It's certainly cool if you can make a single
> > SVG (or other graphic) a separate resource group that can
> > potentially be
> > reused. It's something I'd like to do for PDF at some point.
>
> I do hope Adrian read this as:
> "By all means, if you can extract logic and put it in
> AbstractRenderer, go right ahead." ;-)
>
> Seriously, this would be beneficial to all renderer types, so some of
> it at least deserves a place at the higher level.
>
> Just my two cents.
>
> Cheers
>
> Andreas
Jeremias Maerki
Re: AFP Renderer problems (Re: svn commit: r603590)
Posted by Adrian Cumiskey <ad...@gmail.com>.
Hi Jeremias,
The AFPRenderer should still work fine and produce valid AFP documents, its just source documents
which contain embedded SVG will not be rendered correctly (but will still contain valid AFP). It
should be fine to just update me with the details of your area tree changes and I will make the
necessary adjustments to the AFPRenderer... that'll teach me to work from trunk.. :)
Adrian.
Jeremias Maerki wrote:
> Thanks for the feedback. It's certainly cool if you can make a single
> SVG (or other graphic) a separate resource group that can potentially be
> reused. It's something I'd like to do for PDF at some point.
>
> The reason I was pinging you was that I'm working on that semantic
> change in the area tree I was writing about last week. Since the
> AFPRenderer is currently broken and you're working on it I will not be
> able to adjust the AFPRenderer to that semantic change. I'll just fix
> the other renderers and will inform you about the details. Can you then
> do the necessary adjustments in the AFPRenderer? It won't be too hard.
> Thanks.
>
> On 15.01.2008 17:25:14 Adrian Cumiskey wrote:
>> Hi Jeremias,
>>
>> I have tested the AFP output with a number of applications and the AFPRenderer is at fault here.
>> The GOCA should have been included as part of an overlay rather than just added to the current page.
>> But in doing so would break the current way that documents are constructed by the AFP datastream.
>>
>> Another issue which is related to this implementation is the more general way that resources
>> (images/graphics/fonts etc) are handled (or not). Currently the AFP renderer simply creates a new
>> copy of the resource object with a unique name and embeds it directly in the current page. So I am
>> looking at adding some flexibility here so that resource objects are not duplicated and are instead
>> included and stored (keeping their original source name) within a resource group. A configurable
>> option will also be provided so you are able to set the level at which you would like the resources
>> to be stored (externally, print-file, document, page-group or page). When this is done I will use
>> the this new implementation to include graphics objects correctly.
>>
>> Adrian.
>>
>> Jeremias Maerki wrote:
>>> Adrian,
>>>
>>> do you have an update on this topic? It would be good to know if the IE
>>> plug-in is at fault or the AFPRenderer.
>>>
>>> On 14.12.2007 15:31:19 Jeremias Maerki wrote:
>>>> FO file is attached (to be run from the FOP root directory).
>>>>
>>>> Expectation: see out.pdf
>>>> Effective output in AFP plug-in for IE: see screenshot-ie-afp.png
>>>>
>>>> (produced with FOP Trunk rev 604185)
>>>>
>>>> It could very well be that the IE plug-in has a problem here. I have no
>>>> other viewer to check against.
>>>>
>>>> On 14.12.2007 14:58:39 Adrian Cumiskey wrote:
>>>>> Jeremias Maerki wrote:
>>>>>> I only have the IE plugin. No AFP hardware to test with. snif.
>>>>>>
>>>>>> Basically, it was just a:
>>>>>> <fo:block>
>>>>>> <fo:external-graphic src="test/resources/images/img-w-size.svg"/>
>>>>>> </fo:block>
>>>>>>
>>>>>> No special configuration (i.e. the defaults). Really the simplest of
>>>>>> possible cases and it came out wrong.
>>>>> How did you expect it to come out? How do you think it is wrong?
>>>>>
>>>>> Adrian.
>>>>
>>>>
>>>> Jeremias Maerki
>>>
>>>
>>>
>>> Jeremias Maerki
>>>
>>>
>
>
>
>
> Jeremias Maerki
>
>
Re: AFP Renderer problems (Re: svn commit: r603590)
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jan 15, 2008, at 17:53, Jeremias Maerki wrote:
Hi guys
Sorry to interrupt (currently being completely AFP-agnostic :-))
> Thanks for the feedback. It's certainly cool if you can make a single
> SVG (or other graphic) a separate resource group that can
> potentially be
> reused. It's something I'd like to do for PDF at some point.
I do hope Adrian read this as:
"By all means, if you can extract logic and put it in
AbstractRenderer, go right ahead." ;-)
Seriously, this would be beneficial to all renderer types, so some of
it at least deserves a place at the higher level.
Just my two cents.
Cheers
Andreas
Re: AFP Renderer problems (Re: svn commit: r603590)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Thanks for the feedback. It's certainly cool if you can make a single
SVG (or other graphic) a separate resource group that can potentially be
reused. It's something I'd like to do for PDF at some point.
The reason I was pinging you was that I'm working on that semantic
change in the area tree I was writing about last week. Since the
AFPRenderer is currently broken and you're working on it I will not be
able to adjust the AFPRenderer to that semantic change. I'll just fix
the other renderers and will inform you about the details. Can you then
do the necessary adjustments in the AFPRenderer? It won't be too hard.
Thanks.
On 15.01.2008 17:25:14 Adrian Cumiskey wrote:
> Hi Jeremias,
>
> I have tested the AFP output with a number of applications and the AFPRenderer is at fault here.
> The GOCA should have been included as part of an overlay rather than just added to the current page.
> But in doing so would break the current way that documents are constructed by the AFP datastream.
>
> Another issue which is related to this implementation is the more general way that resources
> (images/graphics/fonts etc) are handled (or not). Currently the AFP renderer simply creates a new
> copy of the resource object with a unique name and embeds it directly in the current page. So I am
> looking at adding some flexibility here so that resource objects are not duplicated and are instead
> included and stored (keeping their original source name) within a resource group. A configurable
> option will also be provided so you are able to set the level at which you would like the resources
> to be stored (externally, print-file, document, page-group or page). When this is done I will use
> the this new implementation to include graphics objects correctly.
>
> Adrian.
>
> Jeremias Maerki wrote:
> > Adrian,
> >
> > do you have an update on this topic? It would be good to know if the IE
> > plug-in is at fault or the AFPRenderer.
> >
> > On 14.12.2007 15:31:19 Jeremias Maerki wrote:
> >> FO file is attached (to be run from the FOP root directory).
> >>
> >> Expectation: see out.pdf
> >> Effective output in AFP plug-in for IE: see screenshot-ie-afp.png
> >>
> >> (produced with FOP Trunk rev 604185)
> >>
> >> It could very well be that the IE plug-in has a problem here. I have no
> >> other viewer to check against.
> >>
> >> On 14.12.2007 14:58:39 Adrian Cumiskey wrote:
> >>> Jeremias Maerki wrote:
> >>>> I only have the IE plugin. No AFP hardware to test with. snif.
> >>>>
> >>>> Basically, it was just a:
> >>>> <fo:block>
> >>>> <fo:external-graphic src="test/resources/images/img-w-size.svg"/>
> >>>> </fo:block>
> >>>>
> >>>> No special configuration (i.e. the defaults). Really the simplest of
> >>>> possible cases and it came out wrong.
> >>> How did you expect it to come out? How do you think it is wrong?
> >>>
> >>> Adrian.
> >>
> >>
> >>
> >> Jeremias Maerki
> >
> >
> >
> >
> > Jeremias Maerki
> >
> >
Jeremias Maerki
Re: AFP Renderer problems (Re: svn commit: r603590)
Posted by Adrian Cumiskey <ad...@gmail.com>.
Hi Jeremias,
I have tested the AFP output with a number of applications and the AFPRenderer is at fault here.
The GOCA should have been included as part of an overlay rather than just added to the current page.
But in doing so would break the current way that documents are constructed by the AFP datastream.
Another issue which is related to this implementation is the more general way that resources
(images/graphics/fonts etc) are handled (or not). Currently the AFP renderer simply creates a new
copy of the resource object with a unique name and embeds it directly in the current page. So I am
looking at adding some flexibility here so that resource objects are not duplicated and are instead
included and stored (keeping their original source name) within a resource group. A configurable
option will also be provided so you are able to set the level at which you would like the resources
to be stored (externally, print-file, document, page-group or page). When this is done I will use
the this new implementation to include graphics objects correctly.
Adrian.
Jeremias Maerki wrote:
> Adrian,
>
> do you have an update on this topic? It would be good to know if the IE
> plug-in is at fault or the AFPRenderer.
>
> On 14.12.2007 15:31:19 Jeremias Maerki wrote:
>> FO file is attached (to be run from the FOP root directory).
>>
>> Expectation: see out.pdf
>> Effective output in AFP plug-in for IE: see screenshot-ie-afp.png
>>
>> (produced with FOP Trunk rev 604185)
>>
>> It could very well be that the IE plug-in has a problem here. I have no
>> other viewer to check against.
>>
>> On 14.12.2007 14:58:39 Adrian Cumiskey wrote:
>>> Jeremias Maerki wrote:
>>>> I only have the IE plugin. No AFP hardware to test with. snif.
>>>>
>>>> Basically, it was just a:
>>>> <fo:block>
>>>> <fo:external-graphic src="test/resources/images/img-w-size.svg"/>
>>>> </fo:block>
>>>>
>>>> No special configuration (i.e. the defaults). Really the simplest of
>>>> possible cases and it came out wrong.
>>> How did you expect it to come out? How do you think it is wrong?
>>>
>>> Adrian.
>>
>>
>>
>> Jeremias Maerki
>
>
>
>
> Jeremias Maerki
>
>
Re: AFP Renderer problems (Re: svn commit: r603590)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Adrian,
do you have an update on this topic? It would be good to know if the IE
plug-in is at fault or the AFPRenderer.
On 14.12.2007 15:31:19 Jeremias Maerki wrote:
> FO file is attached (to be run from the FOP root directory).
>
> Expectation: see out.pdf
> Effective output in AFP plug-in for IE: see screenshot-ie-afp.png
>
> (produced with FOP Trunk rev 604185)
>
> It could very well be that the IE plug-in has a problem here. I have no
> other viewer to check against.
>
> On 14.12.2007 14:58:39 Adrian Cumiskey wrote:
> > Jeremias Maerki wrote:
> > >
> > > I only have the IE plugin. No AFP hardware to test with. snif.
> > >
> > > Basically, it was just a:
> > > <fo:block>
> > > <fo:external-graphic src="test/resources/images/img-w-size.svg"/>
> > > </fo:block>
> > >
> > > No special configuration (i.e. the defaults). Really the simplest of
> > > possible cases and it came out wrong.
> >
> > How did you expect it to come out? How do you think it is wrong?
> >
> > Adrian.
>
>
>
>
> Jeremias Maerki
Jeremias Maerki
Re: AFP Renderer problems (Re: svn commit: r603590)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Oops, forgot the FO file.
On 14.12.2007 15:31:19 Jeremias Maerki wrote:
> FO file is attached (to be run from the FOP root directory).
>
> Expectation: see out.pdf
> Effective output in AFP plug-in for IE: see screenshot-ie-afp.png
>
> (produced with FOP Trunk rev 604185)
>
> It could very well be that the IE plug-in has a problem here. I have no
> other viewer to check against.
>
> On 14.12.2007 14:58:39 Adrian Cumiskey wrote:
> > Jeremias Maerki wrote:
> > >
> > > I only have the IE plugin. No AFP hardware to test with. snif.
> > >
> > > Basically, it was just a:
> > > <fo:block>
> > > <fo:external-graphic src="test/resources/images/img-w-size.svg"/>
> > > </fo:block>
> > >
> > > No special configuration (i.e. the defaults). Really the simplest of
> > > possible cases and it came out wrong.
> >
> > How did you expect it to come out? How do you think it is wrong?
> >
> > Adrian.
>
>
>
>
> Jeremias Maerki
Jeremias Maerki
Re: AFP Renderer problems (Re: svn commit: r603590)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
FO file is attached (to be run from the FOP root directory).
Expectation: see out.pdf
Effective output in AFP plug-in for IE: see screenshot-ie-afp.png
(produced with FOP Trunk rev 604185)
It could very well be that the IE plug-in has a problem here. I have no
other viewer to check against.
On 14.12.2007 14:58:39 Adrian Cumiskey wrote:
> Jeremias Maerki wrote:
> >
> > I only have the IE plugin. No AFP hardware to test with. snif.
> >
> > Basically, it was just a:
> > <fo:block>
> > <fo:external-graphic src="test/resources/images/img-w-size.svg"/>
> > </fo:block>
> >
> > No special configuration (i.e. the defaults). Really the simplest of
> > possible cases and it came out wrong.
>
> How did you expect it to come out? How do you think it is wrong?
>
> Adrian.
Jeremias Maerki
Re: AFP Renderer problems (Re: svn commit: r603590)
Posted by Adrian Cumiskey <ad...@gmail.com>.
Jeremias Maerki wrote:
>
> I only have the IE plugin. No AFP hardware to test with. snif.
>
> Basically, it was just a:
> <fo:block>
> <fo:external-graphic src="test/resources/images/img-w-size.svg"/>
> </fo:block>
>
> No special configuration (i.e. the defaults). Really the simplest of
> possible cases and it came out wrong.
How did you expect it to come out? How do you think it is wrong?
Adrian.
Re: AFP Renderer problems (Re: svn commit: r603590)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 14.12.2007 14:18:36 Adrian Cumiskey wrote:
> Jeremias,
>
> Jeremias Maerki wrote:
> > Adrian,
> >
> > I wanted to plug in the new image package into the AFPRenderer in the
> > branch and found out that I cannot even render the simplest of SVGs
> > (like [1]) after the addition of the Graphics2D implementation here. The
> > image is painted but much too small and in the wrong place.
>
> The example [1] you provide is very small (only 16pt in width and height). I have tested the
> Graphics2D implementation with a number of complicated SVG examples (tax return forms, fractal
> patterns etc). All my tests were done AFP-Lookup Professional, AFP Explorer and IBM's AFP Workbench
> Viewer (which is essentially the same app as the IE plugin), as I've found all of these products to
> be lacking in some way so I use all of them for the purposes of software testing. When I'm happy
> with how the software is interpreting the AFP byte codes I do a hard copy test by sending it to a
> queue on IBM's Infoprint Manager where it is serviced by an IBM Infoprint 1585. Could I ask you how
> you are testing your AFP output and what the context is of referencing the svg file in your fo?
I only have the IE plugin. No AFP hardware to test with. snif.
Basically, it was just a:
<fo:block>
<fo:external-graphic src="test/resources/images/img-w-size.svg"/>
</fo:block>
No special configuration (i.e. the defaults). Really the simplest of
possible cases and it came out wrong.
> > Furthermore, I noticed that there are NullPointerExceptions as soon as a
> > user calls AFPGraphics2D.create() because the parent values are not
> > copied from the parent Graphics2D in the copy constructor.
>
> This is an oversight in my testing, I tested its use only through AFPSVGHandler (which is the
> standard way it is handled). I will fix the copy constructor.
>
> Adrian.
Jeremias Maerki
Re: AFP Renderer problems (Re: svn commit: r603590)
Posted by Adrian Cumiskey <ad...@gmail.com>.
Jeremias,
Jeremias Maerki wrote:
> Adrian,
>
> I wanted to plug in the new image package into the AFPRenderer in the
> branch and found out that I cannot even render the simplest of SVGs
> (like [1]) after the addition of the Graphics2D implementation here. The
> image is painted but much too small and in the wrong place.
The example [1] you provide is very small (only 16pt in width and height). I have tested the
Graphics2D implementation with a number of complicated SVG examples (tax return forms, fractal
patterns etc). All my tests were done AFP-Lookup Professional, AFP Explorer and IBM's AFP Workbench
Viewer (which is essentially the same app as the IE plugin), as I've found all of these products to
be lacking in some way so I use all of them for the purposes of software testing. When I'm happy
with how the software is interpreting the AFP byte codes I do a hard copy test by sending it to a
queue on IBM's Infoprint Manager where it is serviced by an IBM Infoprint 1585. Could I ask you how
you are testing your AFP output and what the context is of referencing the svg file in your fo?
> Furthermore, I noticed that there are NullPointerExceptions as soon as a
> user calls AFPGraphics2D.create() because the parent values are not
> copied from the parent Graphics2D in the copy constructor.
This is an oversight in my testing, I tested its use only through AFPSVGHandler (which is the
standard way it is handled). I will fix the copy constructor.
Adrian.
AFP Renderer problems (Re: svn commit: r603590)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Adrian,
I wanted to plug in the new image package into the AFPRenderer in the
branch and found out that I cannot even render the simplest of SVGs
(like [1]) after the addition of the Graphics2D implementation here. The
image is painted but much too small and in the wrong place.
Furthermore, I noticed that there are NullPointerExceptions as soon as a
user calls AFPGraphics2D.create() because the parent values are not
copied from the parent Graphics2D in the copy constructor.
AFPGraphics2D.create() is called whenever there's a need for a new
coordinate system inside the image (it's the equivalent to gsave/grestore
in PostScript). Maybe you need to test with some more complex SVG and
maybe you need to provide a configurable fallback mechanism to paint
SVGs using bitmaps as long as the Graphics2D implementation is not
stable enough.
[1] https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/test/resources/images/img-w-size.svg
On 12.12.2007 13:24:16 acumiskey wrote:
> Author: acumiskey
> Date: Wed Dec 12 04:24:10 2007
> New Revision: 603590
>
> URL: http://svn.apache.org/viewvc?rev=603590&view=rev
> Log:
> * Added an SVG handler and Graphics2D implementation for AFP which injects AFP GOCA structured fields into the AFPDataStream.
> * Fixed many checkstyle problems.
> * Updated xmlgraphics-commons-1.3svn.jar to include changes to TextHandler
Jeremias Maerki