Prag Programmers style PDF personalization

Any ideas on implementing PDF personalization ala the Pragmatic Programmer e-books with Rails? The source books are already PDFs. I did some experiments using PDFtk, but it seemed a little indirect/

jw

someone documented their experience dealing w/ pdf nonsense: http://ansuz.sooke.bc.ca/software/pdf-append.php

I could imagine that they are rebuiling the whole book from LaTeX sources on every request.

*m

One example is shown over at: http://wiki.rubyonrails.org/rails/pages/HowtoGeneratePDFs In the section PDF Form Fill

Manuel Holtgrewe wrote:

I settled on a Perl solution with PDF::Reuse

but it seems o be impossible to do UTF-8 with it :frowning:

That's because you're asking for something impossible from PDF. You can check the spec if you're interested.

-austin

Would you please elaborate? My idea was not to port PDF::Reuse to Ruby, I am using it as is (especially considering that it's heavily commented in Swedish and I barely understand a word).

I have been producing PDF documents with Russian text for about 5 years now (with other means), as well as copied text from them afterwards.

You could rebuild the whole PDF from LaTeX everytime, as Manuel Holtgrewe suggested, but I think using Postscript would make the process easier and less resource-hungry:

1. Generate a master PostScript file from the LaTeX, with placeholder text in the customizable field (for instance: "Prepared exclusively for <name>") 2. Run sed to replace "<name>" with the new text, then pipe that to ps2pdf

That's because you're asking for something impossible from PDF. You can check the spec if you're interested.

Would you please elaborate? My idea was not to port PDF::Reuse to Ruby, I am using it as is (especially considering that it's heavily commented in Swedish and I barely understand a word).

PDF -- the spec -- does not support UTF-8. Therefore, you cannot use UTF-8 with PDF.

I have been producing PDF documents with Russian text for about 5 years now (with other means), as well as copied text from them afterwards.

Right. That's because *either* the PDF was generated with a Russian font and encoding (for 8-bit values) *or* the PDF was generated with a Unicode font and UTF-16BE encoding.

-austin

That's how we used to do it, but when we have a lot of requests for PDFs (which we do when we announce a new version of the Rails Beta, for example) it was too slow.

We now use a commercial product designed to do just this--stamp stuff onto PDF pages.

Cheers

Dave

Talking about AWDWR2-beta, is there any date for the new iteration?

Care to share what product that is, Dave? I've tried a few and they all suck royally when put under any load. Most of the ones I've found are meant for personal use, or for someone to be right there doing it manually.

--Jeremy

When it's done... :slight_smile:

I'm just about finished ActionPack, but the change to Reloadable means I have to rework the Depot code from the cart onwards, and rewrite those three pages in the cart creation chapter... :frowning:

It's pdstamp.

Product works fine for us. Company it comes from is not the easiest to deal with.

Dave

It doesn't matter for me that much as long as it's Unicode, be it UTF16BE, LE or 32 or 8. The fact is that I can't for the life of me figure out how to pipe unicode text to be stamped in the "default" fonts. Just a thought of using special (especially Unicode) fonts on OSS platforms together with that tool sends shivers down my spine.

You will refer me to the complete obscure PDF spec once again so I will shut up now. I wonder how your solution handles Unicode text, but I admit I'm too lazy to try it out (and the question of PDF re-use as opposed to PDf creation is more important for me right now).

It doesn't matter for me that much as long as it's Unicode, be it UTF16BE, LE or 32 or 8. The fact is that I can't for the life of me figure out how to pipe unicode text to be stamped in the "default" fonts. Just a thought of using special (especially Unicode) fonts on OSS platforms together with that tool sends shivers down my spine.

Um. I'm not sure that the default fonts are Unicode capable.

You will refer me to the complete obscure PDF spec once again so I will shut up now. I wonder how your solution handles Unicode text, but I admit I'm too lazy to try it out (and the question of PDF re- use as opposed to PDf creation is more important for me right now).

PDF::Writer doesn't solve the Unicode problem yet.

-austin

Which brings our Unicode discussion that once happened into new light :slight_smile: thanks for the statement

Not really. The Unicode problem for PDF support is wholly unrelated to my stance on Unicode vs. m17n Strings. The Unicode problem for PDF support is mostly that the PDF standards doc is a stinking pile that is almost impossible to understand without your eyes bleeding and even harder to implement. :wink:

Most strings are written one way for normal 8-bit strings in PDF; they're written an entirely different way when using UTF-16BE. I just haven't got the output format working yet. The *only* thing that would help me with the m17n String and PDF is that I could forcibly convert between encoding-x and UTF-16 for output -- but a Unicode string would leave me less able to deal with this sort of stuff nicely.

-austin

I just couldn't miss a chance to shake the stick in the notion of "I did implement Unicode in my app, why didn't you?" But the way it seems to work in PDF is indeed inexplicably terrible, so this should wait. Although that makes PDF::Writer unusable for my for just about any purpose (except formatting subversion changelogs and other ppurely programming-related documentation that is guaranteed to be ASCII). hope you pardon my pun.

I will try to contact the pdstamp people and ask them how they handle the problem, I might need a Unicode-aware stamper soon.