Return-Path: Delivered-To: apmail-xmlgraphics-general-archive@www.apache.org Received: (qmail 21319 invoked from network); 13 Apr 2006 15:52:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 13 Apr 2006 15:52:07 -0000 Received: (qmail 4471 invoked by uid 500); 13 Apr 2006 15:52:05 -0000 Mailing-List: contact general-help@xmlgraphics.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@xmlgraphics.apache.org Delivered-To: mailing list general@xmlgraphics.apache.org Received: (qmail 4460 invoked by uid 99); 13 Apr 2006 15:52:05 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Apr 2006 08:52:05 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [213.239.215.103] (HELO tux17.hoststar.ch) (213.239.215.103) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Apr 2006 08:52:04 -0700 Received: from [127.0.0.1] (zux221-083-059.adsl.green.ch [81.221.83.59]) (authenticated bits=0) by tux17.hoststar.ch (8.12.11/8.12.11) with ESMTP id k3DFpoPE006726 for ; Thu, 13 Apr 2006 17:51:51 +0200 Date: Thu, 13 Apr 2006 17:51:22 +0200 From: Jeremias Maerki To: general@xmlgraphics.apache.org Subject: Re: Graphics2D implementations (was: Release coordination in XML Graphics) In-Reply-To: <1144941097.19348.19.camel@sellman-r-1.hpl.hp.com> References: <20060413162943.9F96.DEV@jeremias-maerki.ch> <1144941097.19348.19.camel@sellman-r-1.hpl.hp.com> Message-Id: <20060413174001.9FA0.DEV@jeremias-maerki.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.12.01 [en] X-Antivirus: avast! (VPS 0615-2, 04/12/2006), Outbound message X-Antivirus-Status: Clean X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On 13.04.2006 17:11:37 Peter West wrote: > On Thu, 2006-04-13 at 16:37 +0200, Jeremias Maerki wrote: > > On 13.04.2006 16:19:08 Peter West wrote: > > > > > > The Transcoders use the Graphics2D implementations to render the basic > > > > graphic elements. Special elements like links, text and more can > > > > optionally handled using special "bridge" classes (SVG/Batik-specific). > > > > > > > Text which uses either the base14 or embedded fonts seems to be > > > rendering without invoking the bridge classes. In general, text should > > > be able to be rendered through Graphics2D. For the base14 fonts, some > > > extra work is required, but for fonts which are being embedded, the > > > bridge should not be required, should it? In fact, for base14, it is > > > only the co-ordination with the font configuration that's required, > > > isn't it? > > > > Not quite. All text from Batik is normally painted by internally > > converting it to shapes. This is done using the fonts that are available > > to the Java2D subsystem and has nothing to do with font configuration > > provided by FOP. > > > > Only when we register a bridge class for text painting can we select > > simple-enough text elements that we can paint using native operators. > > Only in this case will base 14 fonts (or configured fonts - the > > PDFTextPainter doesn't really care) be used. That's when our own font > > system kicks in. > > > > Let's back up a step. That's text from Batik. Right. Should have said that. > But is Batik needed to render text in a PDFGraphics2D? No, it shouldn't be like that. See below. > Can FOP render text as well as graphics without involving Batik? Yes, actually I forgot a little detail before: PDFGraphics2D implements the two drawString() variants and uses native text commands there. These methods are never called by Batik, but other applications might use them. This is actually one of the reasons I factored out the TextHandler interface in the PSGrahics2D in Commons. So that I didn't take the font subsystem dependecy over, yet. Especially, since FOrayFont will come into play at some point. Factoring out text painting makes the transition easier while still keeping all doors open and it concentrates all text handling in a shorter class. The PDFTextPainter currently simply delegate the actual text painting to the drawString() methods, while PSTextPainter now uses the TextHandler interface (which doesn't exist for PDF, yet). There's certainly room for improvement in this area and it is all work-in-progress but for most purposes everything works fine ATM. Jeremias Maerki --------------------------------------------------------------------- Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org For additional commands, e-mail: general-help@xmlgraphics.apache.org