Pdf::Writer and "Replacement Tags"

Having read over the ruby pdf generation (simple reporting) options, I
think Pdf::Writer will do just fine…

…if the following is possible

On page 13 of (the really expansive) ::Writer manual, Replacement Tags
are detailed.

Before I jump into this tomorrow, I’m hoping for some triage sage
advice.

Finally, the question : “Would utilizing Replacement Tags be a suitable
solution for injecting ActiveRecord contents (datafields, etc) ?”

From the aforementioned page "
Replacement tags will replace the tag with a value computed by the
callback. It may perform additional processing, but no location
information is provided to the callback. The return from this callback
must be the string that will replace the tag. A replacement tag looks
like this in text:
<r:xref name=“FontFamilies” label=“title” />
"

If so, then the PWD format would be a reasonable solution for generating
database driven reports; Injecting row level data on each callback -
this implies that I can retain a static reference to a row.

There are no code samples (that I could see) to help out, but on the
demo page there is a ominous note:
(http://ruby-pdf.rubyforge.org/pdf-writer/demos/index.html):
“code.rb: An example of a custom text formatting tag. Note that this tag
doesnâ??t quite work as it should because of an as-yet unidentified bug in
PDF::Writerâ??s tag handling code.”

Will I encounter this bug?

Any takers? Thank you for any suggestions or lookouts.

Austin, if you’re out there I’d appreciate your thoughts.

cheers,
Jodi

On 14/12/05, Jodi S. [email protected] wrote:

Having read over the ruby pdf generation (simple reporting) options, I
think Pdf::Writer will do just fine…

…if the following is possible

On page 13 of (the really expansive) ::Writer manual, Replacement Tags
are detailed.

Replacement tags are simply ways to programmatically insert text or
other tags. I am using this in the manual code (PDF::TechBook) to
replace <r:xref> tags with internal link tags (<c:ilink>). That way, I
can just put something like:

<r:xref name=“EmbeddingFonts” label=“title” />

which will be replaced with:

<c:ilink dest=‘tgEmbeddingFonts’>Embedding Fonts</c:ilink>

It’s not really what you want for writing reports or injecting
ActiveRecord contents unless you’re entirely working with a template,
which isn’t really something that is built-in for PDF::Writer at this
point.

Tags are specifically meant to replace text within PDF::Writer#text
calls, which is essentially what PDF::TechBook uses. It’s a callback,
not a general text insertion method.

-austin

Austin Z. * [email protected]
* Alternate: [email protected]

On 14/12/05, Jodi S. [email protected] wrote:

It’s not really what you want for writing reports or injecting
ActiveRecord contents unless you’re entirely working with a template,
which isn’t really something that is built-in for PDF::Writer at this
point.

Tags are specifically meant to replace text within PDF::Writer#text
calls, which is essentially what PDF::TechBook uses. It’s a callback,
not a general text insertion method.
Why do you say that it’s not a general text insertion method?

It seems to me (perhaps why I’m asking the question) that essentially
a PWD could be considered a “template” - A. layout considerations
which when utlized with B. <r: /> tags could function as a rudimentary
pdf template.

Right. And that’s certainly a good way to handle it, but to do that you
need the interpreter for that, which is PDF::TechBook. I think that the
way that most people use PDF::Writer right now is to dynamically
generate all of the text and formatting using custom code similar to
what you see in the demo programs. If you’re doing that, or even the
partial generation technique detailed in my Ruby Code & Style article
(where you generate most of the format first and then fill things in
later when you need it), then using a <r: /> tag makes no sense, since
you’re able to insert whatever text you want in whatever way you want.

I would be surprised, myself, if people are using the TechBook
formatter/interpreter, because it does make a few assumptions on how
things are supposed to work. :wink:

I think the callback could be leveraged to provide powerful insertion
functionality.

It could.

Is there a good reason (like speed, or some limit on functionality)
why your tool shouldn’t be used in this manner?

It’s just not something that I would have imagined that it would be that
useful. If it works for you, it shouldn’t be that differentt.

In the past I commited patches to iText - and found it’s html->pdf
worked very well - where my custom tags mapped to our persistance
mapper. Your solution caught my eye as I figured I could build
templates to render pdf rather quickly.

Cool. Like I said, I think you could do it, it’s just not the way that I
would do it simply because I haven’t got a true “html->pdf” converter at
this point.

-austin

Austin Z. * [email protected]
* Alternate: [email protected]

Thanx Austin.

It’s not really what you want for writing reports or injecting
ActiveRecord contents unless you’re entirely working with a template,
which isn’t really something that is built-in for PDF::Writer at this
point.

Tags are specifically meant to replace text within PDF::Writer#text
calls, which is essentially what PDF::TechBook uses. It’s a callback,
not a general text insertion method.

Why do you say that it’s not a general text insertion method?

It seems to me (perhaps why I’m asking the question) that essentially a
PWD could be considered a “template” - A. layout considerations which
when utlized with B. <r: /> tags could function as a rudimentary pdf
template.

I think the callback could be leveraged to provide powerful insertion
functionality.

Is there a good reason (like speed, or some limit on functionality) why
your tool shouldn’t be used in this manner?

In the past I commited patches to iText - and found it’s html->pdf
worked very well - where my custom tags mapped to our persistance
mapper. Your solution caught my eye as I figured I could build templates
to render pdf rather quickly.

Thanx for your thoughts.
Jodi

-austin

Austin Z. * [email protected]
* Alternate: [email protected]