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 > <[email protected]>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 <[email protected] >>> 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 <[email protected] >>>>> 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. >>>>>>> >>>>>> >>>>>> >>>> >>>> >> >>
