font error message

[PhilterPaper]

I have some users of PDF::Table who want to add some kind of markup (italics, color, bold, etc.) to cell contents, so I suggested that they take a look at Text::Layout. It occurred to me that it would be a good idea to check out the behavior of the latest release (0.25), and to see for myself what kind of modifications that PDF::Table might need, as well as adding some instructions on how to best integrate Text::Layout into a PDF::Table-using program.

Unfortunately, when I run the sample code given in Layout.pm's POD, it fails with

Cannot find font: times normal normal at C:\Users\Phil\Desktop\Text-Layout\sample.pl line 15.

That's the set_font_description() line, which requests 40pt Times Roman. It happens in both PDF::API2 and PDF::Builder.

Does this work OK on your Linux setup? If it's a Windows-specific problem (Win10), I can run test programs with diagnostics, etc. for you.

A couple of separate questions:

1. The documentation mentions that "logical" and "ink" extents will be the same on PDF. Is there any practical advice on allowing for this on PDF, i.e., anything to watch out for?
2. What is the difference between get_extents() and get_pixel_extents()? Is one of them in PDF units (points)? What other places do I need to convert Pango units (or whatever) into points (and vice-versa)?

[sciurius]

Hi Phil,

Did you register the font family? E.g.

    my $fd = Text::Layout::FontConfig->new;
    $fd->register_font( "Times-Roman",       "times"               );
    $fd->register_font( "Times-Bold",        "times", "Bold"       );
    $fd->register_font( "Times-Italic",      "times", "Italic"     );
    $fd->register_font( "Times-BoldItalic",  "times", "BoldItalic" );

Or, to register all core fonts:

    Text::Layout::FontConfig->register_corefonts;

On Linux it will fall back to the fontconfig system, so it will automatically find a suitable (replacement) font for Times.

A couple of separate questions:

1. I have only font metrics and bounding boxes to calculate the logical extents. Apparently Pango has other means to calculate extents, post-renderer maybe, to determine where ink did hit the page. For most practical purposes, I'd say the difference is neglectible.
2. See https://metacpan.org/pod/Text::Layout#Pango-coordinates and https://metacpan.org/pod/Text::Layout#Pango-device-units . But there is a 'To Be Discussed' note there...

[PhilterPaper]

I used only the example you gave in the POD (and README). It sounds like the POD needs updating to add a font registration step. I put that in, and the example seems to run OK now. On to experimenting with extent calls!

If the practical difference between logical and ink extents is negligible, it can be set aside for the time being. At some point in the future there may arise cases where some sort of compensation for the difference will be needed (in PDF output).

I tried both get_extents() and get_pixel_extents() to see if one of them appears to be points. Both return the same values in the example (155.3, 0, 439.7, 36), and for both ink and logical (all four cases). I'll have to read up on the dimension/coordinate stuff to see how this maps to points.

The next step will be to see if I can set the output width to cause this to fit into a table cell of arbitrary width. I'm assuming that this will wrap text -- a simple "greedy" algorithm without hyphenation, I would guess.

[sciurius]

By default Text::Layout uses PDF coordinates.

Yes, setting width will invoke a wrapping mechanism. Nothing fancy, as you may have guessed.

[PhilterPaper]

If I have further non-font issues or questions, I'll open a new ticket. Closing.