pdfbox-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maruan Sahyoun <sahy...@fileaffairs.de>
Subject Re: [jira] Commented: (PDFBOX-688) Refactoring rendering-related classes/methods for extensibility
Date Sun, 11 Apr 2010 07:04:22 GMT
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 <sahyoun@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.

View raw message