|
Hi all,
I've tried to collect Zend_Pdf functionality requests and bring them into one list. It's placed in FW wiki now (http://framework.zend.com/wiki/x/45Y). I ordered it by a priority I think items should have. May be something is missing in this list? Or priority should be changed? Thoughts, comments, suggestions are welcome! With best regards, Alexander Veremyev. No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.14/1100 - Release Date: 30.10.2007 18:26 |
|
Hi
It's just a suggestion. It would be nice to draw SVG images (Zend_pdf_image). Here is a link to a class that creates pdf with svg embedded: http://www.godisaduck.com/file/svgload.zip?id=86&type=zip Best regards holo |
|
Hi
> It's just a suggestion. It would be nice to draw SVG images > (Zend_pdf_image). See: http://www.mail-archive.com/fw-general@.../ msg03895.html . I (personally) think that the future is in the PHP- Cairo bindings, which Zend_pdf could then wrap around to provide convenience functions. Although I think it will be a while before the Cairo bindings attain widespread usage. Regards, Freddie. |
|
In reply to this post by Alexander Veremyev
Yeah, good idea. It already was requested at least one time.
I've just added it into the list. With best regards, Alexander Veremyev. > -----Original Message----- > From: Holografix [mailto:[hidden email]] > Sent: Thursday, November 01, 2007 9:04 PM > To: Alexander Veremyev > Cc: [hidden email]; [hidden email] > Subject: Re: [fw-general] Zend_Pdf requirements > > Hi > > It's just a suggestion. It would be nice to draw SVG images > (Zend_pdf_image). > > Here is a link to a class that creates pdf with svg embedded: > http://www.godisaduck.com/file/svgload.zip?id=86&type=zip > > Best regards > holo > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.503 / Virus Database: 269.15.14/1100 - Release Date: > 30.10.2007 18:26 > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.14/1100 - Release Date: 30.10.2007 18:26 |
|
In reply to this post by Alexander Veremyev
Hi Alexander, I used Zend_Pdf extensively in one of my projects and these are features I missed the most: -tables -text blocks -links (pdf reader will recognize full urls, but I couldn't find a way to output link with arbitrary name) Cheers
|
|
I'd like to second Karol's request for text block formatting. IMHO, I think text blocks (with automatic line/page breaks and alignment) should be moved up the priority list. This is the missing feature preventing me from using Zend_Pdf right now. Respectfully, Bryce Lohr Karol Grecki wrote: Hi Alexander, I used Zend_Pdf extensively in one of my projects and these are features I missed the most: -tables -text blocks -links (pdf reader will recognize full urls, but I couldn't find a way to output link with arbitrary name) Cheers Alexander Veremyev wrote:Hi all, I've tried to collect Zend_Pdf functionality requests and bring them into one list. It's placed in FW wiki now (http://framework.zend.com/wiki/x/45Y). I ordered it by a priority I think items should have. May be something is missing in this list? Or priority should be changed? Thoughts, comments, suggestions are welcome! |
|
In reply to this post by Alexander Veremyev
Personally, I'd like to see support for vector EPS images. Even minimal support for older formats would be nice. -CD |
|
I'll second that.
Charlie Dover wrote: > > Personally, I'd like to see support for vector EPS images. Even > minimal support for older formats would be nice. > > -CD > -- Jack |
|
In reply to this post by Charlie Dover
Hi.
> Personally, I'd like to see support for vector EPS images. Even > minimal support for older formats would be nice. I believe it is possible to include PDF files using Zend_Pdf and so using a utility such as epstopdf you can convert your EPS images to PDF files which you can then include in Zend_Pdf documents. Regards, Freddie. |
|
In reply to this post by Bryce Lohr-2
Is there an actual feature in the pdf spec for handling text blocks or will the zend library handle measuring and wrapping the text and then simply drawing each line in it's respective location on the page?
On Nov 2, 2007, at 6:42 AM, Bryce Lohr wrote:
|
|
In reply to this post by Alexander Veremyev
Hi Alexander,
I'd like to see the security features moved up. The actual algo used to encrypt/decrytp doesn't matter right now. But get the essential API down with a pluggable encryption architecture. The actual encryption scheme likely has other uses and could be factored out. Zend_Encrypt or something. cheers, pat |
|
In reply to this post by Rick Gigger-2
I'm not PDF expert, but by my understanding, there's not formal text
block construct in the PDF spec. Zend_Pdf would have provide that
feature, and do the calculations to translate it to the appropriate PDF
code. This is what the other PDF classes I've used do (namely R&OS
and FPDF).
Regards, Bryce Lohr Rick Gigger wrote: Is there an actual feature in the pdf spec for handling text blocks or will the zend library handle measuring and wrapping the text and then simply drawing each line in it's respective location on the page? |
|
In reply to this post by Alexander Veremyev
I noticed that you intend to add "Full UTF-8 support". Last time I
investigated using unicode directly in pdfs I concluded that you could only use unicode in a pdf if you also embedded a unicode font into the pdf. This was a long time ago and it's possible I was incorrect in that conclusion. But I am curious as to how you are planning on implementing this. My understanding is that you have to either embed the unicode font, or convert each bit of text to other non-unicode encodings. I would love it if I was wrong and it was now possible to include unicode directly in the pdf without having to embed the font. On Nov 1, 2007, at 11:23 AM, Alexander Veremyev wrote: > Hi all, > > I've tried to collect Zend_Pdf functionality requests and bring them > into one list. It's placed in FW wiki now (http://framework.zend.com/wiki/x/45Y > ). > > I ordered it by a priority I think items should have. > > May be something is missing in this list? Or priority should be > changed? > Thoughts, comments, suggestions are welcome! > > > With best regards, > Alexander Veremyev. > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.503 / Virus Database: 269.15.14/1100 - Release Date: > 30.10.2007 18:26 > > |
|
In reply to this post by Alexander Veremyev
I am currently using both R&OS PDF and FPDF. I'm going to need to add
support for both Japanese and Chinese soon. I am planning on either updating one or both of those those two pdf engines to handle unicode or switching over to Zend_Pdf entirely and adding in the support there for that. I know that I can just extend FPDF to work if I need to but I don't know if I could just extend Zend_Pdf or if I would need to actually patch the code to Zend_Pdf itself. Of course if I could discuss my implementation with a Zend_Pdf developer and gain confidence that my changes could be incorporated into Zend_Pdf that would be optimal. Also if Zend_Pdf completes Full UTF-8 support before I do that would be even better. Just looking for ways to share the load, if anyone here is interested in discussing this with me please drop me a line, on or off the list. Thanks, Rick On Nov 1, 2007, at 11:23 AM, Alexander Veremyev wrote: > Hi all, > > I've tried to collect Zend_Pdf functionality requests and bring them > into one list. It's placed in FW wiki now (http://framework.zend.com/wiki/x/45Y > ). > > I ordered it by a priority I think items should have. > > May be something is missing in this list? Or priority should be > changed? > Thoughts, comments, suggestions are welcome! > > > With best regards, > Alexander Veremyev. > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.503 / Virus Database: 269.15.14/1100 - Release Date: > 30.10.2007 18:26 > > |
|
Just FYI (in case you're not already aware), R&OS and FPDF both have
several features (particularly with text formatting, such as automatic line and page breaks, automatic text positioning) that are not currently implemented in Zend_Pdf. You will probably want to keep that in mind, since you're most likely using those features right now. HTH, Bryce Lohr Rick Gigger wrote: > I am currently using both R&OS PDF and FPDF. I'm going to need to add > support for both Japanese and Chinese soon. I am planning on either > updating one or both of those those two pdf engines to handle unicode > or switching over to Zend_Pdf entirely and adding in the support there > for that. I know that I can just extend FPDF to work if I need to but > I don't know if I could just extend Zend_Pdf or if I would need to > actually patch the code to Zend_Pdf itself. Of course if I could > discuss my implementation with a Zend_Pdf developer and gain > confidence that my changes could be incorporated into Zend_Pdf that > would be optimal. > > Also if Zend_Pdf completes Full UTF-8 support before I do that would > be even better. Just looking for ways to share the load, if anyone > here is interested in discussing this with me please drop me a line, > on or off the list. > > Thanks, > > Rick > > > > On Nov 1, 2007, at 11:23 AM, Alexander Veremyev wrote: > >> Hi all, >> >> I've tried to collect Zend_Pdf functionality requests and bring them >> into one list. It's placed in FW wiki now >> (http://framework.zend.com/wiki/x/45Y). >> >> I ordered it by a priority I think items should have. >> >> May be something is missing in this list? Or priority should be changed? >> Thoughts, comments, suggestions are welcome! >> >> >> With best regards, >> Alexander Veremyev. >> >> No virus found in this outgoing message. >> Checked by AVG Free Edition. >> Version: 7.5.503 / Virus Database: 269.15.14/1100 - Release Date: >> 30.10.2007 18:26 >> >> |
|
Yes, I was aware of those. I don't use them because I implemented my
own xml based solutions that has support for tables, page breaking, columns, full rich text support, etc. The basic support in those two engines was never enough. All I really need are the primitives to measure, style and draw text, and of course primitive line and shape drawing operations. I have an abstraction layer that lets me swap back and forth between R&OS and FPDF. My XML parser / DOM style rendering library handles the rest. So I don't think it would be too hard to use Zend_Pdf instead. I have also used the extensions listed on the FPDF homepage to add Chinese and other multi-byte languages to PDFs. It is fairly straightforward. The bigger issue is that all of these examples involve using local encodings, not unicode. Once you start wanting to throw unicode in there it gets a little tricky. The PDF renderer needs to map the text it is trying to render to an available font. Unfortunately none of the standard PDF fonts are unicode fonts. So if you want to be able to actually put unicode text in and have it understood then you have to (if I am reading the spec correctly) embed the unicode font right into the PDF . Licensing issues aside entire unicode fonts are about 10-20 Mb. Most of the PDFs I generate are under 50 Kb so that's certainly not going to work. So what I am left with is to determine the language of each block of text and convert it to a local encoding that the PDF spec will happily accept. That seems a little tricky. Say you have a small segment of Japanese with only a few Kanji characters. How do I distinguish that from a few characters of Traditional Chinese? Lets say I figure that part out but then they have say Korean mixed into the same text with Japanese. I have to split out the Korean from the Japanese and draw them separately each time converting to a local encoding and indicating the correct font to use. Anyway that is the problem as I see it. Once I get this figured out I would happily contribute any or all of it to Zend_Pdf if the author wants it. I have this hope that someone working on the Zend_Pdf is going to say that I've read the spec all wrong and that I can somehow add unicode text directly to the pdf and have the PDF reader map it all to a unicode font if present or into the various non-unicode local fonts if if it's not. And of course if whoever is working on the UTF-8 support for Zend_Pdf figures it all out and implements it I'll be more than happy to just switch my rendering engine to just use Zend_Pdf for primitives and get the unicode support for free. Hopefully this will spark some discussion about the implementation of such a feature. Also if this is not the correct list for this sort of discussion could someone please direct me to the correct place. Thanks, Rick On Nov 7, 2007, at 3:47 PM, Bryce Lohr wrote: > Just FYI (in case you're not already aware), R&OS and FPDF both have > several features (particularly with text formatting, such as > automatic line and page breaks, automatic text positioning) that are > not currently implemented in Zend_Pdf. You will probably want to > keep that in mind, since you're most likely using those features > right now. > > HTH, > Bryce Lohr > > > Rick Gigger wrote: >> I am currently using both R&OS PDF and FPDF. I'm going to need to >> add support for both Japanese and Chinese soon. I am planning on >> either updating one or both of those those two pdf engines to >> handle unicode or switching over to Zend_Pdf entirely and adding in >> the support there for that. I know that I can just extend FPDF to >> work if I need to but I don't know if I could just extend Zend_Pdf >> or if I would need to actually patch the code to Zend_Pdf itself. >> Of course if I could discuss my implementation with a Zend_Pdf >> developer and gain confidence that my changes could be incorporated >> into Zend_Pdf that would be optimal. >> >> Also if Zend_Pdf completes Full UTF-8 support before I do that >> would be even better. Just looking for ways to share the load, if >> anyone here is interested in discussing this with me please drop me >> a line, on or off the list. >> >> Thanks, >> >> Rick >> >> >> >> On Nov 1, 2007, at 11:23 AM, Alexander Veremyev wrote: >> >>> Hi all, >>> >>> I've tried to collect Zend_Pdf functionality requests and bring >>> them into one list. It's placed in FW wiki now (http://framework.zend.com/wiki/x/45Y >>> ). >>> >>> I ordered it by a priority I think items should have. >>> >>> May be something is missing in this list? Or priority should be >>> changed? >>> Thoughts, comments, suggestions are welcome! >>> >>> >>> With best regards, >>> Alexander Veremyev. >>> >>> No virus found in this outgoing message. >>> Checked by AVG Free Edition. >>> Version: 7.5.503 / Virus Database: 269.15.14/1100 - Release Date: >>> 30.10.2007 18:26 >>> >>> |
|
Rick Gigger wrote: > Yes, I was aware of those. I don't use them because I implemented my > own xml based solutions that has support for tables, page breaking, > columns, full rich text support, etc. The basic support in those two > engines was never enough. All I really need are the primitives to > measure, style and draw text, and of course primitive line and shape > drawing operations. I have an abstraction layer that lets me swap > back and forth between R&OS and FPDF. My XML parser / DOM style > rendering library handles the rest. So I don't think it would be too > hard to use Zend_Pdf instead. That sounds really interesting... I can see why switching to Zend_Pdf wouldn't be too hard at that point. > The PDF renderer needs to map the text it is trying to render to an > available font. Unfortunately none of the standard PDF fonts are > unicode fonts. So if you want to be able to actually put unicode text > in and have it understood then you have to (if I am reading the spec > correctly) embed the unicode font right into the PDF . Licensing > issues aside entire unicode fonts are about 10-20 Mb. Most of the > PDFs I generate are under 50 Kb so that's certainly not going to > work. So what I am left with is to determine the language of each > block of text and convert it to a local encoding that the PDF spec > will happily accept. That seems a little tricky. fonts. Meaning, you would only have to embed the glyphs you actually used in the document. Seemingly, you could do that with the Unicode font to drastically bring down the size requirement. > > Say you have a small segment of Japanese with only a few Kanji > characters. How do I distinguish that from a few characters of > Traditional Chinese? Lets say I figure that part out but then they > have say Korean mixed into the same text with Japanese. I have to > split out the Korean from the Japanese and draw them separately each > time converting to a local encoding and indicating the correct font to > use. > > Anyway that is the problem as I see it. Once I get this figured out I > would happily contribute any or all of it to Zend_Pdf if the author > wants it. I have this hope that someone working on the Zend_Pdf is > going to say that I've read the spec all wrong and that I can somehow > add unicode text directly to the pdf and have the PDF reader map it > all to a unicode font if present or into the various non-unicode local > fonts if if it's not. And of course if whoever is working on the > UTF-8 support for Zend_Pdf figures it all out and implements it I'll > be more than happy to just switch my rendering engine to just use > Zend_Pdf for primitives and get the unicode support for free. > spec, nor have I worked much with the Zend_Pdf code, so I unfortunately don't have any answers, here. I suppose you could just build a PDF file with all those characters, and see if it comes out as gibberish. Regards, Bryce Lohr |
|
On Nov 8, 2007, at 7:30 AM, Bryce Lohr wrote: > > Rick Gigger wrote: >> The PDF renderer needs to map the text it is trying to render to an >> available font. Unfortunately none of the standard PDF fonts are >> unicode fonts. So if you want to be able to actually put unicode >> text in and have it understood then you have to (if I am reading >> the spec correctly) embed the unicode font right into the PDF . >> Licensing issues aside entire unicode fonts are about 10-20 Mb. >> Most of the PDFs I generate are under 50 Kb so that's certainly not >> going to work. So what I am left with is to determine the language >> of each block of text and convert it to a local encoding that the >> PDF spec will happily accept. That seems a little tricky. > I'm no PDF expert, but for some reason I thought you could embed > partial fonts. Meaning, you would only have to embed the glyphs you > actually used in the document. Seemingly, you could do that with the > Unicode font to drastically bring down the size requirement. Oh yeah. That is one other possibility. So that just leaves the problem of how to do that. :) I think I will investigate that options as well. |
|
In reply to this post by Rick Gigger
Rick Gigger wrote:
> Yes, I was aware of those. I don't use them because I implemented my > own xml based solutions that has support for tables, page breaking, > columns, full rich text support, etc. The basic support in those two > engines was never enough. All I really need are the primitives to > measure, style and draw text, and of course primitive line and shape > drawing operations. I have an abstraction layer that lets me swap back > and forth between R&OS and FPDF. My XML parser / DOM style rendering > library handles the rest. So I don't think it would be too hard to use > Zend_Pdf instead. Great! Any way of contributing your code to the community? I just started to switch from PEAR::File_PDF to Zend_Pdf but I'm kind of disappointed that Zend_Pdf is still at the same spot as a year ago what concerns improved text functions. I played around with Zend_Pdf_Cell presented in issue http://framework.zend.com/issues/browse/ZF-1254 but it does not work as expected (e.g. character width is not calculated correctly, center alignment is no real center alignment, line wrapping does not seem to work at all,...). We all would terribly appreciate your piece of code! Take care Philip |
|
On Nov 8, 2007, at 9:26 AM, Philip Iezzi wrote:
> Rick Gigger wrote: >> Yes, I was aware of those. I don't use them because I implemented my >> own xml based solutions that has support for tables, page breaking, >> columns, full rich text support, etc. The basic support in those two >> engines was never enough. All I really need are the primitives to >> measure, style and draw text, and of course primitive line and shape >> drawing operations. I have an abstraction layer that lets me swap >> back >> and forth between R&OS and FPDF. My XML parser / DOM style rendering >> library handles the rest. So I don't think it would be too hard to >> use >> Zend_Pdf instead. > > Great! Any way of contributing your code to the community? > I just started to switch from PEAR::File_PDF to Zend_Pdf but I'm > kind of disappointed that Zend_Pdf is still at the same spot as a > year ago what concerns improved text functions. > I played around with Zend_Pdf_Cell presented in issue http://framework.zend.com/issues/browse/ZF-1254 > but it does not work as expected (e.g. character width is not > calculated correctly, center alignment is no real center alignment, > line wrapping does not seem to work at all,...). > We all would terribly appreciate your piece of code! I can make the existing code available right now if people want it but I think some code cleanup and documentation would be needed before it could be accepted into something like Zend Framework. If anyone wants to help out with that effort that would be great. The biggest issue is that the XML format is mostly in my head and only documented in stuff that I have already done so in order to figure out how to use it you have to have access to examples or you have to pick through the code. Also as with most first attempts at something complicated you finish it up, get it working and finally know the way it really should have been done in the first place. So I think the best thing would be to start a clean implementation now. I can start with basic rich text / wrapping / alignment features. I will be able to copy most of that over directly from the existing project because that code is very good and is actually more of a 4th or 5th generation product. I started off doing simple text wrapping and alignment on R&OS PDF about 5 years ago and it has evolved significantly since then. That should be immediately useful to people and could be used on top of Zend_Pdf without actually modifying it. First will come the DOM objects for doing the rendering and shortly thereafter I will include an extensible XML parser so that creating documents and testing will be much easier. Then I can start to add stuff like tables and columns and other layout features where I will need to do a little more R&D. Eventually if the Zend people want to start incorporating it into the framework they will be more than welcome to. I would be willing to help out with the integration where my time and expertise permits. The only thing that has really been keeping me from releasing this stuff in the past (other than time of course) is that I didn't know anyone who was interested in it. If I could get some feedback from you guys as I go it would be very helpful to me. One thing to keep in mind is that my DOM is loosely based on XHTML. I have drawn most of my tag names from it and am in the middle of a rudimentary CSS implemention to abstract some of the style information out of the XML. I have made specific changes though for precision placement of layout items and for precise control of page breaking and associated needs. For example I have attributes on table headers to control whether or not they repeat if the table is broken across multiple pages. I don't see any reason though that someone couldn't write a completely different XML layer (FOP?) and use my DOM objects underneath. That is where all the real work is anyway. The drawback there is that the naming of the DOM objects will in most instances correspond with HTML tag names and their functionality will be geared towards my view of what you need to do proper PDF layouts, which may be very different from something like FOP. My impression of FOP was that it might be great but it was a little too ambitions. I say that with regards to both implementing and using it. By focusing on a subset of XHTML I was able to get the functionality that I needed working quickly and it is somewhat intuitive to learn for anyone who has done even basic HTML work. Anyway anyone who is interested let me know and I will notify you (or should I just notify the list) when I have something ready for you to download. Thanks, Rick |
| Powered by Nabble | Edit this page |
