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 Mon, 12 Apr 2010 16:23:48 GMT
just wanted to share my thoughts ;-) 

Maruan Sahyoun

Am 12.04.2010 um 18:03 schrieb Daniel Wilson:

> No objection to the capitalization change.  As I just submitted this last
> night, I am probably the only one w/ anything depending on that name.
> I think your view of the separation of platform classes from PDF classes
> makes a lot of sense.
> My use of PDFBox is fairly narrow (as is that of many users), so I would
> like to hear from Andreas or Jukka before committing to anything too major,
> though.
> Daniel
> On Mon, Apr 12, 2010 at 10:56 AM, Maruan Sahyoun <sahyoun@fileaffairs.de>wrote:
>> Hi Daniel,
>> I think it's a good first step. Having thought about that a little more the
>> question to me becomes if it makes sense to even refactor that a bit more as
>> the font handling still contains some platform specific things as now we
>> have getawtFont. What if the PD classes are PDF related and application or
>> platform specific stuff ends in PageDrawer and some new classes let's call
>> them platform classes for the moment. This way PageDrawer would use the
>> platform classes to get the font which then would use the PDxxx classes to
>> get the information necessary  to "generate" the right information.
>> Currently PDxxx is a mixture of PDF specific classes and routines and non
>> PDF specific things like returning a java font. Factoring non PDF related
>> stuff out would provide a better separation and also the chance to provide
>> additional implementations for specific applications e.g. let's say we would
>> like to render PDF to HTML we could implement  a HTML rendition without
>> touching the "core" PDF stuff.
>> If that's a good idea really depends on where PDFBox should go. Currently
>> looking at the issues in JIRA and the users mailing list I see a number of
>> different types of applications where people are trying to use PDFBox - from
>> text extraction to printing to a Reader type application.  In addition to
>> that there is also some "core" functionality missing. If there are layers
>> like "core", "platform" and "application" I think development would benefit.
>> As I'm new to PDFBox (and as I wouldn't say that a) I have seen all code
>> and b) understood how all the stuff works together) this reflects my current
>> understanding.
>> And I'm also not a Java expert (although I do most of my development in
>> Java).
>> Last comment ;-) I would call the method getAwtFont and not getawtFont.
>> Kind regards
>> Maruan Sahyoun
>> Am 12.04.2010 um 15:20 schrieb Daniel Wilson:
>>> 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 <sahyoun@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 <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.
>>>>>> judicious refactoring permits PageDrawer to be extended in .Net and
>> key
>>>>>> methods to be overriden.
>>>>>>>> I am continuing this refactoring for better rendering support
>> .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