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

[Fabien T. <ft...@ol...>]

	Hi,

According to Aaron J Mackey:
> 
> Some initial commits in Page.pm will be coming shortly (fillout the
> graphics primitives).

wonderful :)
 
> I'd still like to hear what you think about my earlier proposal
> (Create::Page::Text and Create::Page::Polygon) with associated add_text(),
> and add_polygon() methods in Create::Page.

Sure. Here it is..

> > You wrote :

> I think better in code, see if you like this example:
> 
> use PDF::Create;
> 
> $pdf = new PDF::Create %parameters; # filename, author, etc.
> 
> my $root = $pdf->new_page(%parameters); # media box, etc.
> 
> my $page1 = $root->new_page();
> 
> my $f1 = $pdf->font(%parameters); # subtype, encoding, base, etc.

ok.. (nothing's changed 'til there)
 
> # parameters here are things like the text itself, font, font size,
> # character width, spacing, kerning properties, etc.:
> my $text1 = $pdf->text(%parameters); # text1 isa PDF::Create::Text

ok.
 
> # 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 ?

> if($text1) {
>     # do something else with this text, perhaps move into another column,
>     # a different page, whatever.
> }

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
}

> # 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 ?

> # for colors, we need to handle rgb, cmyk, etc. colorspaces.  Allow
> # export of rgb(), cmyk(), gray() functions, or use them from
> # PDF::Create::rgb(), all of which create very lightweight colorspace
> # objects that our functions know how to deal with.
> 
> $black = PDF::Create::rgb(255, 255, 255); # $black is a PDF::Create::Color
> $white = PDF::Create::cmyk(0, 0, 0, 0);
> $gray10 = PDF::Create::gray(0.1);
> 
> # change some default values for a page.
> $page->setfill($black); # uses a PDF::Create::Color object
> $page->setstroke(255, 255, 255); # since @_ == 3, we guess rgb

looks good.
 
> $page->line(x1, y1, x2, y2, %parameters);

hmm.. already there but need to be changed to accept parameters.
 
> # draw an arc, but use a stroke color different from page's default:
> $page->arc(c1, c2, width, heigth, from, to, 'strokecolor' => $gray);
> 
> # 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 :

  with 'strokecolor' value in $x...

  $ref = ref $x;
  !defined $ref && do {
     # gray 
  } ||
  $ref eq 'ARRAY' && do {
    my $n = scalar @$x;
    $n == 3 && do {
      # rgb
    } ||
    $n == 4 && do { 
      # cmyk
    } || croak "unrecognized";
  } ||
  $ref eq 'PDF::Create::Color' && do {
    # already a color obj
  } || croak "unrecognized";

> # Now, make a polygon to be drawn:
> my $poly = $page->new_polygon(@xypoints);
> $poly->add_point(x, y);
> $poly->transform(dx, dy, etc);
> 
> $page->polygon($poly, %parameters);

ok.

> # or draw the polygon directly; we can distinguish parameter attributes
> # from points by m/^\d+$/
> $page->polygon(@xypoints, %parameters);

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. 

my $d = $pdf->new_drawing(%parameters);
$d->add($poly, location, transformation);
$d->add($arc, ...);
$d->add($line1, $arc3);
$d->transform(...);
$page->draw($d, %params);

we can also allow "paths" built using low level methods..

> $pdf->close;
> 
> __END__
> 
> So, in summary:
> 
> PDF::Create::Page handles all actual drawing and parameters thereof.
> PDF::Create::Text and PDF::Create::Polygon are containers of text/points
> 
> So, it seems natural to me that PDF::Create::Text should contain
> information about the text's font, spacing, width, etc., but an argument
> could be made that, like PDF::Create::Polygon, it should only hold the
> text itself, and support methods to help draw it (which accept all the
> parameters about font, size, spacing, kerning, etc).  Let me know your
> thoughts.

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.

>  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 

-- 
Fabien Tassin -+- ft...@ol...