Re: [Perl-pdf-devel] ready, set, go

[Aaron J M. <aj...@vi...>]

Good morning,

On Thu, 17 Feb 2000, Fabien Tassin wrote:

> > # parameters here are placement, bounding box, justification;
> > # drawtext returns a new textobject containing any leftover text
> > # which couldn't be drawn within the constraints provided, else undef
> > $text1 = $page1->drawtext($text1, %parameters);
> 
> hmm.. why a "new" object ? why not just modify (shrink ?) the given one ?
> 
> I see your goal.. hmm, what about this ?
> 
> my $text = $pdf->text(data => $data, %otherparams);
> my $page = $pdf->new_page;
> while ($page->drawtext($text, %params)) { # write as long as needed
>   $page = $root->new_page; # next page
> }

So, I think a combination of our ideas may be the best bet.  I was
returning a new object (or a shrunken original object), and just
reassigning for visual affect - making it very clear that the original
object is being changed and may have leftover text in it.

I think we need to return information about where the current point is
when we're done drawing text, or some information about the current text
matrix (CTM).  This information will be critical for text decoration
(adding link objects, or graphical objects that need to align with text).
This could be stored (and set) in the $text object itself.

$text = $pdf->new_text(%params);
$page = $root->new_page(%params);

$page->drawtext($text, %params);

if($text->remaining_data()) {
    # handle remaining data however you want - new page, new column, etc.
}

# or, in a while loop:

while($text->remaining_data()) {
    $page = $root->new_page();
    $page->drawtext($text, %params);
}

> > # placetext acts as drawtext, but doesn't actually draw anything, just
> > # reports the actual space taken up by the text.  drawtext() could do the
> > # same thing if called in array context (returning first any leftover text
> > # followed by the resulting bounding box.
> > my ($x1, $y1, $x2, $y2) = $page1->placetext($text1, %parameters);
> 
> what is the purpose of this method ?

The purpose of this method is to perform the placement calculations that
would have been performed for drawtext and report back what the result
would be if the text had actually been drawn.

Let's say that you have a paragraph of text that needs to fit in a certain
area, and that you'd like to draw a rectangle around the text.  If the
text doesn't completely fill the area, you'd like to draw your rectangle a
little smaller.  If the text would completely fill the area without any
remaining text, no problems.  If the text would overflow the area, then
you'd like to actually print as much as you can in the area, minus a
little space for a "... continued page 5" line.  To do all this you need
to be able to find out "what would happen if I sent drawtext this text
object?"


> > # or, do some fancy parameter checking when we run into 'color'
> > # attribute, or other potentially multiparameter attribute:
> > $page->arc(c1, c2, width, height, from, to, 'strokecolor' => 0.1);
> 
> or allow both :

Of course; that's actually what I meant in my two examples, that we would
handle all cases:

    # Easy cases to handle:
    $page->arc(c1, c2, w, h, f, t, 'strokecolor' => 0.1); # grayscale

    $page->arc(c1, c2, w, h, f, t, 'strokecolor' => $red); # color object

    $page->arc(c1, c2, w, h, f, t, 'strokecolor' => [0, 0, 0]); # rgb ARRAY

    $page->arc(c1, c2, w, h, f, t, 'strokecolor' => [1, 1, 1, 1]); # cmyk ARRAY

    # this is trickier: requires us to forward-check @_ for \d+, and
    # isn't very perlish, but still very possible to implement.
    $page->arc(c1, c2, w, h, f, t, 'strokecolor' => 0, 0, 0); # rgb

    $page->arc(c1, c2, w, h, f, t, 'strokecolor' => 1, 0.5, 1, 0.2); # cmyk

> We need a generic container for complex drawings.. something that can be
> derived to create charts, cartouches or even photos (png, gif, jpeg...) more
> easily. 

I can kinda see why someone might want this, but I don't understand why
they couldn't "encapsulate" the drawing of multiple elements into a
subroutine, not an object?

draw_arrow($page);

sub draw_arrow {

    my $page = shift;

    # ... make an arrow-like polygon, set the line width, color, etc.

    # ... write some text inside the arrow

    # ... draw a circle around the arrow, different linewidth, color, etc.

}

as opposed to having objects for each drawing element (line, arc,
rectangle, :

$arrow = $pdf->new_drawing(%params);

$poly = $pdf->new_polygon(%params); # build arrow-like polygon
$arrow->add_polygon($poly);

$text - $pdf->new_text(%params);
$arrow->add($text);

$circle = $pdf->new_arc(%params);
$arrow->add($circle);

$page->draw($arrow, %params);

# Maybe this stuff is the major advantage:
$arrow->scale(200); # make it all 200% bigger
$arrow->transform(-10, -10, +200, +100); # shrink/stretch it
$arrow->rotate(-12.5); # rotate it -12.5 degrees

$page->draw($arrow, %params);

Hmm, ok I'm more convinced now.  Objectify everything to gain the
advantage of being able to collect and transform en masse.

> My thoughts..
> 
> PDF::Create::Text contains the text itself or a filehandle (to
> avoid big memory usage). It could have its own parameters, fonts, etc
> but they can be changed by the page->drawtext method.

Sounds good to me.  Save the desired "default" parameters for the text
along with the text itself, then allow them to be modified during the
actual drawing process.


> >  Also, if we're going to handle
> > user-supplied font files (.afm or otherwise), or if we're going to ever
> > support kerning, then we'll need to rethink the font strategy (and decide
> > whether to duplicate PostScript::FontMetrics or whatever).
> 
> I'm currently only supporting Type1/WinAnsiEncoding fonts. In the same way,
> the 2 other Type1 font types (MacRomanEncoding & MacExpertEncoding) can be
> added. Other types (Type0, Type3 and TrueType) will probably require
> a separated class (each). We will need a frontend class for this.
> This is for PDF fonts.
> For user supplied fonts, I don't know. TTF will be easy because it's also
> a PDF font type.. AFM is not very difficult either (I've used AFM fonts to
> obtain the WinAnsiEncoding hashes). Well, I 

... ?  I think we should revisit this later.  I've got enough to do for
now ;)

best wishes,

Aaron

-- 
 o ~   ~   ~   ~   ~   ~  o
/ Aaron J Mackey           \
\  Dr. Pearson Laboratory  / 
 \ University of Virginia  \     
 /  (804) 924-2821          \
 \  am...@vi...    /
  o ~   ~   ~   ~   ~   ~  o