pdfbox-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Wilson <williamstonconsult...@gmail.com>
Subject Re: [jira] Commented: (PDFBOX-688) Refactoring rendering-related classes/methods for extensibility
Date Mon, 12 Apr 2010 13:20:55 GMT
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.  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.
> >>>
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message