I need to clip text (e.g. in a table column). Is this already supported? If yes, how can I do it?

Thanks,
Ondrej

Ondrej Pokorny wrote

I need to clip text (e.g. in a table column). Is this already supported?

No, I haven't done any work on using the clipping operators yet. In fpReport, text is rather wrapped than clipped.

Contributions in this regard are obviously very welcome. I would imagine if the clipping operators are to be implemented, then graphics state (save & restore) would probably go hand-in-hand with the clipping too.

Regards,
- Graeme -

A small remark:

If the PDF format does not support some form of clipping natively, then it should not go in fpPDF.

But it should instead be implemented in a layer on top of fppdf, such as the planned TPDFCanvas.

Keep your designs orthogonal, please.

Michael.

Michael Van Canneyt wrote

If the PDF format does not support some form of clipping natively, then it should not go in fpPDF.

PDF supports native clipping on all graphic elements. Glyphs are part of the graphic elements.

The only clipping we currently implement is the MediaBox (ie: the size of the page).

In case somebody else wanted to implement clipping earlier than I can. See page 123 (table 4.1) in the PDF v1.3 specification document. Clipping Paths (W & W*) and Graphics state (q & Q most likely).

Regards,
- Graeme -

Excellent, no problem then :-)

Michael.

I have no idea about graphics state :)

Clipping and multi-line text are probably the last 2 features I miss.

IMO multi-line text support should be added into TFPFontCacheItem. Something like:

TFPFontCacheItem.CalcMultiLineText(const AText: string; const AWidth,
ALineHeight: single; const AAlignment: TTextAlignment): TMultiLineText;
TTextTag = record
   X, Y: Single;
   Text: string;
end;
TMultiLineText = record
   TextTags: array of TTextTag;
end;

The CalcMultiLineText would then calculate the X/Y-position of lines/tags (if justify alignment should be supported.) Then one could easily either draw it on PDF page or TCanvas.

Do you have some function like this in fpReport? Could it be extracted from fpReport into fpTTF? Or should I create one for myself?

Ondrej

Ondrej Pokorny wrote

I have no idea about graphics state :)

PDF does it all for you really. The idea is that you ask PDF to save the current graphics state, apply your clip region, do your drawing or text output, then ask PDF to restore the graphics state (thus remove your clip region). Trick is just to know where to use the "q" and "Q" PDF commands.

Clipping and multi-line text are probably the last 2 features I miss.

So we are getting there. ;-)

IMO multi-line text support should be added into TFPFontCacheItem. Something like:

My only problem with that, and why TextHeight() and TextWidth() is not yet in fpTTF.pas unit, is the 14 PDF built-in fonts. The fontcache might not have actual TTF files for say Helvetica, Times-Roman etc, but you are still allowed to use those in your PDF.

In fpReport I had to generate metric equivalent data (stored in an include file) for all 14 PDF built-in fonts. So TextHeight() and TextWidth() needs to first query if the font in question is a Std PDF Font or not, then it knows to go to the fontcache or to the lookup tables for glyph metric information.

I still need to figure out how to get this cleanly into fpTTF.pas. Part of it (eg: is the font a Std PDF built-in or not) can possibly go into fpPDF, the rest needs to go into fpTTF.pas. But then my other issue with that is that then fpTTF will depend on fpPDF and vice versa. I want to keep dependencies to a minimum. Hence my struggle. :)

Do you have some function like this in fpReport? Could it be extracted from fpReport into fpTTF? Or should I create one for myself?

There is similar functionality in fpReport. I'll see if we can move some of that to fpPDF.

Regards,
Graeme

TextWidth is already in fpTTF / TFPFontCacheItem.

Actually, IMO it should be the programmers responsibility to include TTF files for default PDF fonts if he wants to use TTF features on them. And your problem is solved :)

+ For now fpPDF can render only ASCII glyphs for standard fonts. Is this a limitation of the PDF format? If yes, then the default PDF fonts have to be embedded as TTF anyway in many cases anyway.

> >Do you have some function like this in fpReport? Could it be extracted > >from fpReport into fpTTF? Or should I create one for myself? There is similar functionality in fpReport. I'll see if we can move some of that to fpPDF.

fpTTF is better, IMO. It should be made on TTF-level, not PDF. It would be great if you could move it to fpTTF - it would spare me some time for other things. Although it shouldn't be that hard, but it's still a plus :)

Ondrej

Ondrej Pokorny wrote

TextWidth is already in fpTTF / TFPFontCacheItem.

Yes, but that one only handles TTF fonts that the fontcache found. In fpReport I needed to handle Std PDF fonts too - hence I have separate implementations for TextWidth() and TextHeight().

Actually, IMO it should be the programmers responsibility to include TTF files for default PDF fonts if he wants to use TTF features on them.

True. But not just that. The PDF specification document actually mentions that it is recommended to embed the standard fonts too. The reason being, it is up to the PDF Viewer to find a similar font as Helvetica, Times Roman etc and then use that. This in theory could give you inaccurate PDF rendering results as not all copies of Helvetica, Times Roman etc are equal on the various platforms. Unfortunately not many seem to do this, as everybody likes the small file sizes. ;-)

My recommendation. Don't use the standard PDF a
typography point of view, they are boring and ugly.

+ For now fpPDF can render only ASCII glyphs for standard fonts. Is this a limitation of the PDF format?

I'm not actually 100% sure of that. I think so.

> There is similar functionality in fpReport. I'll see if we can move some > of that to fpPDF. fpTTF is better, IMO. It should be made on TTF-level, not PDF.

You are correct.

Regards,
Graeme

Reading your previous email, my opinion is that TextWidth() and TextHeight() (and other similar functions) should be supported only by fonts that the fontcache found.

If the programmer needs TTF functions on default PDF fonts, he has to make sure the TTF files are available. Easy as that :)

Ondrej