perl-pdf-devel

[Perl-pdf-devel] Color in PDF

[<JDe...@ne...>]

I am interested in getting color in PDF. I am not sure how to do it. I would be glad to put it somewhere in the PDF::Create module if someone can give me some details. All I know is that I need a ColorSpace, but those are usually defined as some binary stream??? I also saw something like

/CS1 1 sc scn

When colors were being changed. I don't know how to make it work, though.
-- 
---------------------------------
-Jeff Delinck (jde...@ne...)

Check out my home pages at
http://sites.netscape.net/JDelinck/ and
http://homepages.go.com/~mickeydink/







__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

[Perl-pdf-devel] PDF::Create and page rotation

[Ewan L. <ej...@ma...>]

I have just started using the PDF::Create module, and am trying to get the
page to rotate 90 degrees (or print in landscape if there's a better way to
do it.

I am currently trying to do this with:

my $root = $pdf->new_page('MediaBox'  =>
$pdf->get_page_size("a4"),'Rotate'=>90)
;

which seems to be correct in the documentation but get the error:

Can't use string ("90") as an ARRAY ref while "strict refs" in use at
/usr/opt/p
erl5/lib/site_perl/5.005/PDF/Create.pm line 194.


Any ideas? I am running 5.005_03 on AIX4.3 with PDF::Create 0.06 downloaded
from Sourceforge.

Thanks in advance,

Ewan Leith

FWL Technologies Ltd
Tel:  0161 283 4040   Fax: 0161 283 4051
Web:  http://www.fwltech.com/logistics
Mailto:ej...@ma...

[Perl-pdf-devel] Re: PDF::create

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

	Hi,

According to Joao Pedro Franco e Silva:
> 
> My name is Joao Silva, I'm from Portugal, and I'm usig your module
> PDF::Create.
> It seems very complete, but I needed to put some images in the documents
> that I'm generating (in PDF) with your module. Is it possible? If not,
> will it be possible? If it's possible, how do I put an image (bitmap,
> gif, eps, etc) in a PDF document with your module?
> 
> Thanks in advanced!

You can't with the current version but it is in our TODO list.
BTW, contributions are welcome :)
Feel free to visit our project page :

	http://sourceforge.net/project/?group_id=2464

Regards.

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

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

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...

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

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

Ok, I've grabbed a CURRENT cvs tree, looks great.

Some initial commits in Page.pm will be coming shortly (fillout the
graphics primitives).

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.  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).

-Aaron


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

Re: [Perl-pdf-devel] Initial SourceForge contact..

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

According to Fabien Tassin:
> 
> According to Aaron J Mackey:
> > 
> > Ok Fabien, I'm registered on SourceForge and I have an account.  There
> > doesn't seem to be any modules available for anonymous checkout, or if
> > there is, I don't know it's name.
> 
> The CVS part is ready but there's no snapshot yet...

oops. I forgot to mention the "modulename".. it's "CURRENT". The idea
is to have 2 CVS branches : CURRENT and STABLE. STABLE contains nothing
yet but will always contain the lastest release (whose that are on CPAN).

To obtain the latest CVS release :

- as anonymous :

$ cvs -d:pserver:ano...@cv...:/cvsroot/perl-pdf login 

<no password needed, just hit enter>

$ cvs -z3 -d:pserver:ano...@cv...:/cvsroot/perl-pdf co CURRENT

- as developper :

$ export CVS_RSH=ssh  (or "setenv CVS_RSH ssh" for csh/tcsh users)
$ cvs -z3 -dY...@cv...:/cvsroot/perl-pdf co CURRENT

where YOURLOGIN is your SourceForce login.

> > I'm happy to send patches if you want to keep sole control over the
> > repository.  Up to you.
> 
> hmm.. I would like to have 2 or 3 commiters for the CVS tree but no
> more. I still don't know how to do this with SourceForge but if you want
> some privileges on this project, no problem. I need your SF login.

you should now be able to commit your changes directly.

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

Re: [Perl-pdf-devel] Initial SourceForge contact..

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

According to Aaron J Mackey:
> 
> Ok Fabien, I'm registered on SourceForge and I have an account.  There
> doesn't seem to be any modules available for anonymous checkout, or if
> there is, I don't know it's name.

The CVS part is ready but there's no snapshot yet...

> I'm happy to send patches if you want to keep sole control over the
> repository.  Up to you.

hmm.. I would like to have 2 or 3 commiters for the CVS tree but no
more. I still don't know how to do this with SourceForge but if you want
some privileges on this project, no problem. I need your SF login.

This is my first SourceForge project. I'm still testing this apparently
great beast.. if it is concluding, I will add my others projects too.

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

[Perl-pdf-devel] test 1 2 3

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

Ok Fabien, I'm registered on SourceForge and I have an account.  There
doesn't seem to be any modules available for anonymous checkout, or if
there is, I don't know it's name.

I'm happy to send patches if you want to keep sole control over the
repository.  Up to you.

-Aaron

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