[jira] Commented: (PDFBOX-688) Refactoring rendering-related classes/methods for extensibility
[ https://issues.apache.org/jira/browse/PDFBOX-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863153#action_12863153 ] Andreas Lehmkühler commented on PDFBOX-688: --- I've found an other call in BeginInlineImage and removed it with version 940253 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 Fix For: 1.2.0 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.
Re: [jira] Commented: (PDFBOX-688) Refactoring rendering-related classes/methods for extensibility
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.dewrote: 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-tabpanelfocusedCommentId=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
Re: [jira] Commented: (PDFBOX-688) Refactoring rendering-related classes/methods for extensibility
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 sahy...@fileaffairs.dewrote: 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
Re: [jira] Commented: (PDFBOX-688) Refactoring rendering-related classes/methods for extensibility
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 sahy...@fileaffairs.dewrote: 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 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
Re: [jira] Commented: (PDFBOX-688) Refactoring rendering-related classes/methods for extensibility
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 sahy...@fileaffairs.dewrote: 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 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
[jira] Commented: (PDFBOX-688) Refactoring rendering-related classes/methods for extensibility
[ https://issues.apache.org/jira/browse/PDFBOX-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.
Re: [jira] Commented: (PDFBOX-688) Refactoring rendering-related classes/methods for extensibility
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-tabpanelfocusedCommentId=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.
