Peter Rabbitson wrote: >Hi everyone, >Today I am stuck with PDF::API2. Although seeming very powerful, the module >documentation is horridly lacking. I was able to figure a great deal of what >I need by directly examining the source, however some issues are left >unsolved: > >1. Is there a way to get the (x,y) pos and maybe more attributes of an >already processed object? I looked all over the place - doesn't look like >there is such a function. Even if I put every single line and dot into a >separate handler - the dump of the structure still does not yield anything. >I need this to be able to do background hilighting - e.g. I placed some text >through handler $some_text, I pass it to the subroutine, it extracts the >starting position, the alignment and the width of the text and creates an >ellipse behind it with a certain fillcolor. I actually have more uses for >that, but this is the main one. > > > Are you rendering the text yourself, or editing an existing PDF? If you're rendering it yourself, then you should be tracking where you're up to. Otherwise, sorry, I haven't editing existing PDFs before.
>2. I don't really understand the entire concept of objectifying content >elements - I can have a $paragraph object handler and use ->text in >conjunction with ->nl to write out an entire paragraph, or I can make a >separate handler for each line - the output doesn't seem to change. In this >case - why the need/possibility for separate handlers? > > I single object reduces the size of the resulting pdf a little. If you have a *lot* of objects, it makes a difference. I'm working on a PDF report writer ( which I'm calling PDF::ReportWriter unless someone objects ), upon reading your post I realised that I was creating a new gfx object each time I was rendering a cell ( box ). When I changed this to only create a new gfx object per page, the PDF dropped from 80k to 32k. I assume a smaller PDF will be rendered to screen faster as well. Another reason why you may want to use separate objects is that this ( apparently ) makes it easier to edit the pdf later ( ie easier to get the part you want, I assume ). As I said, I haven't done this, but I'd read quickly over some else's description of doing it. >3. Is there a difference between methods ->gfx->textlabel and ->text ? I >understand they have a different syntax but they seem to do the same thing >in the end. > > > No idea. >4. Is there vertical alignment for text? Or the font is always centered >between the zone denoted by ->lead ? > > > As far as I know, there is no vertical alignment. >I have seen questions about PDF::API2 on this list before, and here and >there people were suggested to try other modules. Unfortunately >PDF::API2::Lite has 0 documentation and PDF::Report does not seem to be able >to do all the graphics that I would eventually need in my case. So I am >stuck with the vanilla API2. > Yeah that's basically the conclusion I came to. Zero documentation is a big turn-off. That plus Perl programmers find white-space offensive so going through the source code to their work requires a pack of headache tablets. Keep in mind that you don't necessarily have to do all your work with one library. You can do some rendering with one, and then move to another. For example, you could save the PDF and re-open it in another. Alternatively, you can grab the PDF::API2 object and work with it directly. If you're interested, I can email you with my unfinished PDF::ReportWriter ... it's *almost* ready for an initial release. I'm pondering whether I should remove the dodgy hard-coded stuff or not. -- Daniel Kasak IT Developer NUS Consulting Group Level 5, 77 Pacific Highway North Sydney, NSW, Australia 2060 T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 email: [EMAIL PROTECTED] website: http://www.nusconsulting.com.au -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
