What I have done, I consider a step in the right direction, but you may have some better code. I do not develop much in Java, so sometimes I do things in ways that are not that elegant.
I skipped the Type3 fonts in what I did. I saw what was going on & decided I had no idea how to handle it! As for drawString vs TextLayout.getOutline, I really don't know. Sorry I didn't read your comments in 678 well enough. I would have collaborated on the getAwtFont work! Daniel On Sun, Apr 11, 2010 at 3:04 AM, Maruan Sahyoun <sahy...@fileaffairs.de>wrote: > Hi Daniel, > > I think we are currently trying to do the same as I also started > implementing a getAwtFont Method ;-) as outlined in my comments for > PDFBOX-678 in order to get all drawing for the different text modes done in > PageDrawer itself (I think we share the same general idea that there should > be a clearer separation of concerns). I already have that working for > TrueType fonts (just copied the code in writeText into the new method) and > the non clipping text modes. The only difficulty I see is handling e.g. > Type3 fonts as they can not be so easily converted to a font. Maybe we share > ideas how to deal with these and then make a decision who implements what in > order to avoid duplication of efforts. I'm happy to just rely on your > getAwtFont implementation as you might be further down the road. > > One question when drawing text in PageDrawer is how text handling should be > done in general. E.g. using drawString is faster and produces text objects > which can be selected for example when you print to a PDF printer. But > outlines etc. are not possible that way. There I can either use > TextLayout.getOutline() to draw the outline (and combine that with > drawString to get selectable text) or selectable text as a result of > PageDrawer is not important at all. This will then also affect possible > applications in PDFReader which currently is display only - but what is the > idea with that further down the road. > > Maybe there we should also share some thoughts as you will have a much > better idea about the longer term plan for PDFBox as I'm new to that > project. > > Kind regards > > Maruan Sahyoun > > Am 11.04.2010 um 04:32 schrieb Daniel Wilson: > > > Thanks, Maruan. > > > > The big thing to avoid is direct access to a graphics object in an object > > other than PageDrawer. I inherit from PageDrawer and override many of > the > > methods, and I believe anyone else who wishes to use PDFBox for rendering > in > > .Net would need to do the same. > > > > A big hint that direct access to a graphics object is coming is a line of > > code like > > Graphics2D graphics = (PageDrawer)context.getGraphics(); > > > > If that line tries to execute in .Net ... it will return a NULL ... and > then > > you get NullPointerExceptions. > > > > Better to keep the graphics code in PageDrawer. > > > > The refactoring of some of the Font stuff I'm about to commit doesn't > > completely do this ... but it does provide a getawtFont routine that can > be > > called from .Net, permitting the actual graphics stuff down in > PDSimpleFont > > to be avoided. > > > > Daniel > > > > On Fri, Apr 9, 2010 at 2:44 PM, Maruan Sahyoun <sahy...@fileaffairs.de > >wrote: > > > >> Hi Daniel, > >> > >> as I'm currently looking at implementing support for some more text > >> rendering modes in PageDrawer (PDFBOX-678) I would like to understand if > >> that might affect the .NET Version. Although I don't have a completed > >> version this is a list of the potential operations I will be using. > >> > >> * generating a Shape based on TextLayout.getOutline() > >> * filling, drawing and clipping using that Shape > >> * possibly AlphaComposite > >> * possibly GlyphVector > >> > >> Are there things I should avoid? > >> > >> Kind regards > >> > >> > >> Maruan Sahyoun > >> > >> Am 09.04.2010 um 18:18 schrieb Daniel Wilson (JIRA): > >> > >>> > >>> [ > >> > https://issues.apache.org/jira/browse/PDFBOX-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855454#action_12855454 > ] > >>> > >>> Daniel Wilson commented on PDFBOX-688: > >>> -------------------------------------- > >>> > >>> 928957 -- Make page and pageSize available (again) for > >> libraries/applications that inherit. > >>> 931616 -- Stroke & line width/style modifications. > >>> 931633 -- Invoke / drawImage > >>> 932179 -- Don't fail to BLACK quite so quickly ... do some more > >> intelligent guessing. > >>> Necessary when implementing in .Net as there are still > >> some key things IKVM is missing. > >>> > >>>> Refactoring rendering-related classes/methods for extensibility > >>>> --------------------------------------------------------------- > >>>> > >>>> Key: PDFBOX-688 > >>>> URL: https://issues.apache.org/jira/browse/PDFBOX-688 > >>>> Project: PDFBox > >>>> Issue Type: Improvement > >>>> Reporter: Daniel Wilson > >>>> Assignee: Daniel Wilson > >>>> Priority: Minor > >>>> > >>>> Some of the classes/methods in the rendering area assume they have > >> access to a Graphics2D object. > >>>> This assumption breaks when using the .Net version of PDFBox. Some > >> judicious refactoring permits PageDrawer to be extended in .Net and key > >> methods to be overriden. > >>>> I am continuing this refactoring for better rendering support in .Net. > >>>> Andreas recently asked that code committed to SVN also be tied to a > Jira > >> issue -- a good idea really -- so I'm putting this in as an issue. > >>> > >>> -- > >>> This message is automatically generated by JIRA. > >>> - > >>> You can reply to this email to add a comment to the issue online. > >>> > >> > >> > >
