[pdftex] define pdf variable and then reference it?

[James Quirk]

Ivo,

If you're contemplating using sed, I'm assuming your download process will 
be controlled by a cgi process. In which case, you could always use pdftk 
to apply a background to your document, as in:

     pdftk master.pdf background name.pdf output custom.pdf

where name.pdf is generated on the fly from a five line TeX file.
This approach has the advantage that you don't need to muck
around with the innards of the PDF.

James

On Thu, 1 Jun 2006, ivo welch wrote:

> thank you, ross (and martin).
>
> I know even less about FDF than I know about PDF.  Do you have a short
> example template  you could post?
>
> Sticking to the same number of bytes would not be a problem NOW THAT I
> KNOW IT.  I could simply make the defined unusual string pretty long
> (80 characters), and replace it with my string plus spaces.  In my
> application, typesetting would not be a problem---I would probably
> want my pdf document to display the string somewhere on a left side,
> not followed by anything.  (This brings me back to my original
> definition: does pdf have an easy variable mechanism that can be
> resolved at run time?  this would seem a lot easier than the FDF
> multiple request route.)
>
> regards,
>
> /iaw
>
>
> On 6/1/06, Ross Moore <ross at ics.mq.edu.au> wrote:
>> Hello Ivo,
>>
>> On 01/06/2006, at 12:41 PM, ivo welch wrote:
>>
>>> I have a strange question.  I would like to customize a large pdftex
>>> generated document for everyone who downloads it.  For example, I
>>> would like to write in the headings of each page "hello, george".
>>> alas, I do not want to have to re-latex for every downloader.
>>
>> This is hardly strange.
>> There are several sites where this kind of thing is implemented.
>>
>>>
>>> One solution would be to turn off all pdftex compression, and then
>>> look for a very unusual string that I would put into the heading, and
>>> which would be replaced.  (I know that the typesetting of this string
>>> may be off.)  Is this the best solution?
>>
>> Well, it just isn't a solution at all, unless you also ensure
>> that all of your replacement strings have the same lengths;
>> that is, exactly the same number of bytes.
>>
>> On the other hand, the PDF spec allows for incremental changes
>> to be made at the end of a PDF document, with a mechanism to
>> store the complete history of changes.
>> I've only seen Acrobat Pro do this, but doubtless there is other
>> software around that does it also.
>>
>> However, this might cost a significant amount of $s.
>>
>>
>>>
>>> I do not know much about pdf, but if it were to allow me to set a
>>> variable and pdftex were to allow me to use this variable later, it
>>> would solve this very elegantly.  something like
>>>    \pdfdefinevariable{\someheading}{VERYUNUSUALSTRING}
>>>    \pagestyle{myheadings}
>>>    \markboth{\someheading \hfill}
>>> the resolution would occur at display time, not at
>>> latex-typesetting-compile time.  a simple sed program could replace
>>> VERYUNUSUALSTRING with "hello, george", and every page heading would
>>> have "hello, george" on it.
>>
>> Another approach, which *can* be implemented using pdf-TeX and
>> a sripting language (such as Perl), is to make use of JavaScript
>> form fields, and the FDF (Forms Data Format) specification.
>>
>> This works as follows.
>>
>>    When a user clicks a hyperlink to download your document,
>> your web-server sends the request to a script that will be
>> interpreted by the scripting engine (e.g. Perl).
>>
>> This script constructs a short text-file in FDF format,
>> specifying
>>    a.  a URL for the real PDF document
>>    b.  the values of (variable) fields within that PDF.
>>
>> The web-server sends out this FDF file.
>> When the user's browser receives this FDF it will (if
>> configured correctly)
>>    (i)  launch an instance of  Adobe Reader ;
>>   (ii)  emit a request for the real PDF file;
>> (iii)  merge the values contained in the FDF file
>>         with the fields inside the PDF doc
>>
>> Actually it is the Adobe Reader that does steps (ii)
>> and (iii), but it needs to cooperate with the browser
>> to achieve these tasks.
>>
>>
>> The result is similar to what you are asking for.
>> However, you don't get the same typesetting quality
>> that you might like, as the field data must be
>> a flat text-string --- in Unicode, would be best.
>>
>>
>>>
>>> Is the latter possible?  advice appreciated.
>>
>> We use this FDF mechanism a lot with student quizzes.
>> These are personalised for each student. The Perl scripts
>> do a lot more; e.g., keeping track of when requests are
>> made, and from where. They also check whether the student
>> is indeed enrolled in the course, and contribute lines
>> to a personal log of each student's activity concerning
>> these downloadable quizzes.
>>
>> Here's a typical URL for one of our courses:
>>
>> http://rutherglen.ics.mq.edu.au/~maths/S106/123/quizzes.html
>>
>> For the "Name" and "Student ID" try  'guest'  or  'staff'.
>> These names allow the enrolment checking to be bypassed.
>>
>>
>>>
>>> /ivo welch
>>
>> Going back to your original statement of intent ...
>>
>>>   For example, I
>>> would like to write in the headings of each page "hello, george".
>>> alas, I do not want to have to re-latex for every downloader.
>>
>>   ... the re-latex route need not be inappropriate.
>>
>> This is what we do for student assignments, to personalise a cover-sheet
>> for each student.  For example, at:
>>
>>     http://rutherglen.ics.mq.edu.au/~maths/S106/123/assign.html
>>
>> This time the assignment sheets are typeset afresh, using the
>> name and student ID provided from the web-site.
>>
>>
>> For larger documents, there is an interesting strategy that can be
>> used. You pre-load  pdflatex  processes, which run until encoutering
>> a \write18 statement which waits for a specific signal.
>> Such a signal might be the existence of a file containing the name
>> to be used in your running headers.
>> Now your web-server's script gets the information provided by the user
>> and writes it into a file with the prescribed name. This releases
>> the waiting pdflatex job, allowing it to finish. Once done, the
>> web-server serves up the newly created PDF to the user.
>>
>> Provided your document isn't too complicated, this can be quite fast.
>> If you expect a lot of usage, preload hundreds of processes, each
>> with a different trigger.
>>
>> Use of the  pdfpages  package may be appropriate with larger documents,
>> to reduce the amount of time pdfTeX spends in digesting macro
>> expansions.
>>
>>
>>
>> Hope this helps,
>>
>>         Ross
>>
>> ------------------------------------------------------------------------
>> Ross Moore                                         ross at maths.mq.edu.au
>> Mathematics Department                             office: E7A-419
>> Macquarie University                               tel: +61 +2 9850 8955
>> Sydney, Australia  2109                            fax: +61 +2 9850 8114
>> ------------------------------------------------------------------------
>>
>>
>>
> _______________________________________________
> pdftex mailing list
> pdftex at tug.org
> http://tug.org/mailman/listinfo/pdftex
>