Hello,

Graeme has fixed a number of errors that should hopefully solve the problems with codepages; Changes have been tested on windows/linux/bsd but on Windows only with a system that has an english locale.

These changes have been committed to FPC svn. (rev 33453)

We would appreciate it if someone could test the PDF generating demo on a Windows with non-english locale, and report whether the first page of the generated PDF looks OK.

Michael.

Michael Van Canneyt wrote

We would appreciate it if someone could test the PDF generating demo on a Windows with non-english locale, and report whether the first page of the generated PDF looks OK.

I am now testing it. The unittests_console.lpr test fails with:

#0 fpc_raiseexception(0x1a099a4, 0x1, 0x19f6ae0) at P:\software\FPC\trunk_src\rtl\inc\except.inc:158
#1 TASSERT__FAIL(0x1a099a4 '"Failed on Numtables" expected: <19> but was: <18>', 0x433990, 0x5beea4) at .\fcl-fpcunit\src\fpcunit.pp:564 #2 TASSERT__ASSERTTRUE(0x1a099a4 '"Failed on Numtables" expected: <19> but was: <18>', false, 0x433990, 0x5beea4) at
.\fcl-fpcunit\src\fpcunit.pp:591
#3 TASSERT__ASSERTEQUALS(0x5c15dc 'Failed on Numtables', 190000, 180000, 0x5beea4) at .\fcl-fpcunit\src\fpcunit.pp:675
#4 TTESTLIBERATIONFONT__TESTDIRECTORY_NUMTABLES(<error reading variable>) at fpparsettf_test.pas:421
#5 TTESTCASE__RUNTEST(<error reading variable>) at .\fcl-fpcunit\src\fpcunit.pp:1039
#6 TTESTCASE__RUNBARE(<error reading variable>) at .\fcl-fpcunit\src\fpcunit.pp:1006
#7 PROTECTTEST(0x198ab70, 0x19f9fd8) at .\fcl-fpcunit\src\fpcunit.pp:1453 #8 TTESTRESULT__RUNPROTECTED(0x198ab70, 0x4456e0 <PROTECTTEST>, <error reading variable>) at .\fcl-fpcunit\src\fpcunit.pp:1471 #9 TTESTRESULT__RUN(0x198ab70, <error reading variable>) at .\fcl-fpcunit\src\fpcunit.pp:1462
#10 TTESTCASE__RUN(0x19f9fd8, <error reading variable>) at .\fcl-fpcunit\src\fpcunit.pp:996
#11 TTESTSUITE__RUNTEST(0x198ab70, 0x19f9fd8, <error reading variable>) at .\fcl-fpcunit\src\fpcunit.pp:1318
#12 TTESTSUITE__RUN(0x19f9fd8, <error reading variable>) at .\fcl-fpcunit\src\fpcunit.pp:1308
#13 TTESTSUITE__RUNTEST(0x196aa28, 0x19f9fd8, <error reading variable>) at .\fcl-fpcunit\src\fpcunit.pp:1318
#14 TTESTSUITE__RUN(0x19f9fd8, <error reading variable>) at .\fcl-fpcunit\src\fpcunit.pp:1308
#15 TTESTRUNNER__DOTESTRUN(0x196a6c8, <error reading variable>) at .\fcl-fpcunit\src\consoletestrunner.pas:179
#16 TTESTRUNNER__DORUN(<error reading variable>) at .\fcl-fpcunit\src\consoletestrunner.pas:429
#17 TCUSTOMAPPLICATION__RUN(<error reading variable>) at .\fcl-base\src\custapp.pp:343
#18 :28

I downloaded all needed fonts. What am I doing wrong?

Ondrej

Probably the version of the font differs from what Graeme is using. (I also have several errors because of too much font files etc, these are known)

But those are the unit tests.

The test program to use to generate a PDF, is however "examples/testfppdf.lpi"

I should maybe have mentioned that more explicitly.

Michael.

Michael Van Canneyt wrote

The test program to use to generate a PDF, is however "examples/testfppdf.lpi" I should maybe have mentioned that more explicitly.

No problem. Thanks :)
(Still it would be fine to provide links where compatible versions of the fonts can be found.)

Here you go. Win 10, Czech locale.
Original file:
https://drive.google.com/open?id=0Bx-flYubOTroenRQcTRTYTQtYVk

If I set SetMultiByteConversionCodePage(CP_UTF8):
https://drive.google.com/open?id=0Bx-flYubOTroemdJWG5Pb0xCcWc

Btw. you have a typo in the Russian "Hello, word". The first word should be "???????????".

Ondrej

Sorry, I missed the latest revision. I'll update and report back!

Ondrej

Ondrej Pokorny wrote

Sorry, I missed the latest revision. I'll update and report back!

I updated and now SetMultiByteConversionCodePage(CP_UTF8) isn't needed. The files are exactly the same (=the same byte contents) as before with SetMultiByteConversionCodePage(CP_UTF8).

https://drive.google.com/open?id=0Bx-flYubOTroemdJWG5Pb0xCcWc

Some Vietnamese characters and box drawing characters aren't rendered on my system.

Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160408/fab79a0b/attachment-0001.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: diieiffa.png
Type: image/png
Size: 39014 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160408/fab79a0b/attachment-0001.png>

Good to hear that, this is what we were aiming for :-)

Some Vietnamese characters and box drawing characters aren't rendered on my system.

That probably depends on the font, Graeme will be able to say more about it.

Michael.

I've tested it too. Thank you very much for your work!

I've just copied the font FreeSans.ttf from Lazarus\components\aggpas to FPC\packages\fcl-pdf\examples\fonts. It looks fine (Windows 7, 64bit, Lazarus 1.7 r52149 FPC 3.1.1 r33453 i386-win32-win32/win64 German locale):

(60mm,100mm) Times-BoldItalic: Big text at absolute position Languages: English: Hello, World!
Greek: ???? ??? ??????
Polish: Witaj ?wiecie
Portuguese: Ol? mundo
Russian: ???????????? ???
Vietnamese: Xin ch?o th? gi?i
Box Drawing: ? ? ? ? ? ? ? ?
Typography: ?What?s wrong??
?17.99 vs ?17?99
?17.99 vs ?17?99
OK then? ??????????
B ??????? ???????? ???????? ??? ????????? ???? ??????? ????.

As note: If I compile with -Cr, I got a Runerror 201 in unit fpparsettf on line 810.

Kind regards

Michl

Ondrej Pokorny wrote

(Still it would be fine to provide links where compatible versions of the fonts can be found.)

Our internal SVN repo had such a file - albeit not 100% complete.

As Michael mentioned, the unit tests will definitely be dependent on the exact font version. I'll make sure the README file is updated, and try and improve the unit tests to report more sensible errors (if font versions don't match).

Regards,
- Graeme -

Correct, when I took the font from Lazarus\components\aggpas as Michael W. Vogel did, everything looks good!

Ondrej

Michael Van Canneyt wrote

> > Some Vietnamese characters and box drawing characters aren't rendered on my > > system. That probably depends on the font, Graeme will be able to say more about it.

Sjoe, that first PDF got me worried! :-)

It does look like a DejaVu Sans font version mismatch. These open source font files get updated regularly, and I used the latest I could find.

I'll post the exact font files I have. Size and Version. I'll also update that README file I mentioned.

Regards,
- Graeme -

Ondrej Pokorny wrote

Correct, when I took the font from Lazarus\components\aggpas as Michael W. Vogel did, everything looks good!

Awesome!

Just curious. What is your Windows locale set at?

Regards,
- Graeme -

Currently Czech (+Windows 10).

Ondrej

Ondrej Pokorny wrote

Btw. you have a typo in the Russian "Hello, word". The first word should be "???????????".

Not according to Google Translate. :)

[https://translate.google.com/#auto/en/%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D1%81%D1%82%D0%B2%D1%83%D0%BB%D1%82%D0%B5%20%D0%BC%D0%B8%D1%80]

Anyway, I got that text from somewhere on the Internet, and used it for various Unicode text handling. I never really checked how accurate the non-English text was.

Regards,
- Graeme -

Michael W. Vogel wrote

(60mm,100mm) Times-BoldItalic: Big text at absolute position Languages: English: Hello, World! Greek: ???? ??? ??????

If you could copy the text out of the displayed PDF, that means I got the ToUnicode structure correct too. Nice. I forgot to test that one. :)

As note: If I compile with -Cr, I got a Runerror 201 in unit fpparsettf on line 810.

I made a note of that, thanks.

Regards,
- Graeme -

I started testing.

1. Why does TFPFontCacheItem.GetFontData create and load TTFFileInfo every time it is called? As a result TTFFileInfo is created and loaded every time TextWidth is called - there's no way to go around this. The TTFFileInfo should be cached IMO.
Please consider the attached patch.

2. Is gTTFontCache/uFontCacheList really needed? fcl-pdf doesn't use it. The user should create such a variable by himself, IMO.

3. WriteText in combination with custom TTF font doesn't print anything. There should be an exception when calling WriteText with custom TTF font or the call should be redirected to WriteUTF8Text automatically. (See demo code below.)

4. I cannot make TFPFontCacheItem.TextWidth work. (I was able to make "TextWidth" work, though.) Could you please check the code below to see what I am doing wrong? I want to draw a rectangle around text. (I just added a procedure to the example project):

procedure TPDFTestApp.TextBox(D: TPDFDocument; APage: integer);
var
   P : TPDFPage;
   FtTitle: integer;
   xFontCache: TFPFontCacheList;
   xFont: TFPFontCacheItem;
   xWidth, xHeight, xDesc: Extended;
const
   cFontSize = 50;
begin
   P := D.Pages[APage];
   FtTitle := D.AddFont('FreeSans.ttf', 'FreeSans', clGreen);
   P.SetFont(FtTitle, cFontSize);
   P.SetColor(clBlack, false);
   P.WriteText(25, 0, 'Sample Text'); // DOESN'T WORK !!!
   P.WriteUTF8Text(25, 20, 'Sample Text');
   xFontCache := TFPFontCacheList.Create;
   try
     xFont := TFPFontCacheItem.Create('fonts\FreeSans.ttf');
     xFontCache.Add(xFont);
     xWidth := xFont.TextWidth('Sample Text', cFontSize) * 25.4 / 72; //
25.4 / 72 = conversion PDFTomm (?)
     xHeight := xFont.GetFontData.CapHeight * cFontSize * xFontCache.DPI
/ (72 * xFont.GetFontData.Head.UnitsPerEm) * 25.4 / 72;
     xDesc := xFont.GetFontData.Descender * cFontSize * xFontCache.DPI /
(72 * xFont.GetFontData.Head.UnitsPerEm) * 25.4 / 72;
   finally
     xFontCache.Free;
   end;
   P.SetColor(clRed, true);
   P.SetColor($37b344, false); // some green color
   P.SetPenStyle(ppsDashDot);
   P.DrawRect(25, 20-xDesc, xWidth, xHeight, 1, False, True);
end;
Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160409/17e59e8b/attachment.html>
-------------- next part --------------
Index: fpttf.pp
===================================================================
--- fpttf.pp	(revision 33453)
+++ fpttf.pp	(working copy)
@@ -43,11 +43,13 @@
     FFamilyName: String;
     FFileName: String;
     FStyleFlags: LongWord;
+    FFileInfo: TTFFileInfo;
     FOwner: TFPFontCacheList; // reference to FontCacheList that owns this instance
     function    GetIsBold: boolean;
     function    GetIsFixedWidth: boolean;
     function    GetIsItalic: boolean;
     function    GetIsRegular: boolean;
+    procedure   SetFileName(const AFileName: String);
     procedure   SetIsBold(AValue: boolean);
     procedure   SetIsFixedWidth(AValue: boolean);
     procedure   SetIsItalic(AValue: boolean);
@@ -54,11 +56,12 @@
     procedure   SetIsRegular(AValue: boolean);
   public
     constructor Create(const AFilename: String);
-    { Returns the actual TTF font file information. Caller needs to free the returned instance. }
+    destructor  Destroy; override;
+    { Returns the actual TTF font file information. }
     function    GetFontData: TTFFileInfo;
     { Result is in pixels }
     function    TextWidth(AStr: string; APointSize: single): single;
-    property    FileName: String read FFileName write FFileName;
+    property    FileName: String read FFileName write SetFileName;
     property    FamilyName: String read FFamilyName write FFamilyName;
     { A bitmasked value describing the full font style }
     property    StyleFlags: LongWord read FStyleFlags write FStyleFlags;
@@ -147,6 +150,14 @@
   Result := (FStyleFlags and FP_FONT_STYLE_REGULAR)  0;
 end;
+procedure TFPFontCacheItem.SetFileName(const AFileName: String);
+begin
+  if FFileName = AFileName then Exit;
+  FFileName := AFileName;
+  if FFileInfonil then
+    FreeAndNil(FFileInfo);
+end;
+
 procedure TFPFontCacheItem.SetIsBold(AValue: boolean);
 begin
   if AValue then
@@ -192,14 +203,25 @@
   FStyleFlags := FP_FONT_STYLE_REGULAR;
 end;
+destructor TFPFontCacheItem.Destroy;
+begin
+  FFileInfo.Free;
+
+  inherited Destroy;
+end;
+
 function TFPFontCacheItem.GetFontData: TTFFileInfo;
 begin
+  if FFileInfo  nil then
+    Exit(FFileInfo);
+
   if FileName = '' then
     raise ETTF.Create(rsNoFontFileName);
   if FileExists(FileName) then
   begin
-    Result := TTFFileInfo.Create;
-    Result.LoadFromFile(FileName);
+    FFileInfo := TTFFileInfo.Create;
+    FFileInfo.LoadFromFile(FileName);
+    Result := FFileInfo;
   end
   else
     Result := nil;
@@ -262,25 +284,21 @@
     sl.Free;
   {$ENDIF}
-  try
-    lWidth := 0;
-    for i := 1 to Length(AStr) do
-    begin
-      c := AStr[i];
-      lGIndex := lFntInfo.GetGlyphIndex(Ord(c));
-      lWidth := lWidth + lFntInfo.GetAdvanceWidth(lGIndex);
-    end;
+  lWidth := 0;
+  for i := 1 to Length(AStr) do
+  begin
+    c := AStr[i];
+    lGIndex := lFntInfo.GetGlyphIndex(Ord(c));
+    lWidth := lWidth + lFntInfo.GetAdvanceWidth(lGIndex);
+  end;
-    if APointSize = 0.0 then
-      Result := lWidth
-    else
-    begin
-      { Converting Font Units to Pixels. The formula is:
-        pixels = glyph_units * pointSize * resolution / ( 72 points per inch * THead.UnitsPerEm )  }
-      Result := lWidth * APointSize * FOwner.DPI / (72 * lFntInfo.Head.UnitsPerEm);
-    end;
-  finally
-    lFntInfo.Free;
+  if APointSize = 0.0 then
+    Result := lWidth
+  else
+  begin
+    { Converting Font Units to Pixels. The formula is:
+      pixels = glyph_units * pointSize * resolution / ( 72 points per inch * THead.UnitsPerEm )  }
+    Result := lWidth * APointSize * FOwner.DPI / (72 * lFntInfo.Head.UnitsPerEm);
   end;
 end;

You should learn how to use Google Translate :) The page you link here shows you the typo explicitely just below the original text...

Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160409/b430616a/attachment-0001.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: dbjgjifi.png
Type: image/png
Size: 13939 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160409/b430616a/attachment-0001.png>

Please don't take it as an offence, there is no.
I just first opened the PDF, saw the typo and then I had to check in the source code if it is really a typo or the library picks up the wrong character for the PDF. It is a typo, so everything is OK. It would be still great if you corrected it ;)
Correct is "????????????" (I missed a character in the first email as well :D)

Ondrej

Ondrej Pokorny wrote

4. I cannot make TFPFontCacheItem.TextWidth work. (I was able to make "TextWidth" work, though.)

That should read: (I was able to make "*TextHeight*" work, though.)

Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160409/aaaf3d16/attachment.html>

Well, I thought so too, but I am not a native Russian speaker, so it is not my place to make comments :-)

Fixed in rev. 33456.

Michael.

Ondrej Pokorny wrote

You should learn how to use Google Translate :)

I use it a lot.

The page you link here shows you the typo explicitely just below the original text...

Okay, but clicking on the second link below the one you are referring to, and you still get "Hello World". I don't know Russian at all, so I really don't know if it is correct or not. My point is, I know you get a ton of slight variations in language terms (no matter the language) and often related to context. Such terms often translate to the same English term.

Anyway, no offence taken, I'll update the text.

[...seconds later...]

Ah, I see Michael already fixed it. Thanks M.

Regards,
- Graeme -

Hi,

I'm on my way out, so can't comment on all parts right now.

There is still quite a few improvements that need to be made to fpPDF - features and some tweaks to the API.

As for WriteText() versus WriteUTF8Text(). These grew from the fact that Standard built-in PDF Fonts were implemented first, then TTF. The API stuck around, but needs improving. There really should be overloaded WriteText(), then internally the current font should be queried and then decide which internal text processing methods to call. Standard PDF Fonts and TTF Fonts have very different text and font info handling.

More accurate API names would have been WriteStdFontText() and WriteTTFFontText(), but that looks hideous too. ;-)

Regards,
- Graeme -

An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160409/2791c51a/attachment.html>

On Fri, Apr 8, 2016 at 3:22 PM, Michael Van Canneyt wrote:
[...]

After this update, it worked fine here on my PC (Windows 7 pt-BR), I just changed the demo to using arial.ttf instead of freessans.

The demo should have an IFDEF to using Arial instead of FreeSans on Windows, this would avoid problems for beginners. :-)

The generated PDF after the changes:
https://dl.dropboxusercontent.com/u/135304375/test.pdf.

interesting in what determines "correct"...

???? ???!
?????? ???!
???????????? ???!

Glad to hear it;
We'll change the demo with the IFDEF, we should be kind to beginners :-)

Other demo apps are of course welcome. Please keep in mind they must compile without LCL etc. if they are to be included in FPC itself.

Well, at least after an initial false start, we can now actually start improving the API. Suggestions always welcome.

Thanks to everyone for testing !

Michael.

That's my point exactly. I've seen the same thing in fpGUI's translation files. Many different terms, all apparently meaning the same thing. Some were considered "old style language" others "modern language usage", some based on Context.

I'm no language or translation expert - thank goodness. Trying to teach my son the rules of the English language and all its "exceptions to the rule" is enough! :)

Regards,
- Graeme -

"Correct" as I used it was about a typo in one of the words you presented. It wasn't about word choice.

Ondrej

Michael Van Canneyt wrote

Fixed in rev. 33456.

Thanks :)

Ondrej

Il 09/04/2016 16:47, Graeme Geldenhuys ha scritto:

Given the context, which is to test a PDF generator, and not to find the best way to greet the world in Russian :-) , I'd say that ???????????? ???! is to be preferred, because it has a higher number of characters! Even better would be ???????????? ??????????????? ???????, meaning "Computer".

Giuliano*
*

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160409/e338f994/attachment.html>

I see that the PDF generator doesn't support image compression. This is a no-go in my eyes. Is anybody working on that or should I try to study it?

AFAIR SynPDF uses JPEG compression for images.

Ondrej

An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160409/e4a1d879/attachment.html>

oh! in that case, carry on! :) O:)

Ondrej Pokorny wrote

I see that the PDF generator doesn't support image compression. This is a no-go in my eyes. Is anybody working on that or should I try to study it?

We are not yet working on this, it was on the TODO list, but not very high priority.

AFAIR SynPDF uses JPEG compression for images.

Patches will gladly be accepted.

Michael.

Great, I'll take a look into it. It is high priority for me. As is the text width function (for right/center alignment support).

If there is a possibility to render text with custom TTF font in Lazarus (I found easylazfreetype, but I couldn't make it work with my first attempts), I think I'll develop a TPDFDocument->TCanvas renderer for previewing created PDF documents.

Ondrej

Ondrej Pokorny wrote

I see that the PDF generator doesn't support image compression. This is a no-go in my eyes. Is anybody working on that or should I try to study it?

It's on the todo list, as is Text Compression, Font Subset Embedding and many more. You are welcome to tackle parts you deem urgent for your needs.

Reducing the size of generated PDF's are high on the priority list, but what was even higher was actually getting a working PDF. Based on the latest round of feedback, the latter goal has finally been reached. So the next goals will be ticked off one by one.

Regards,
- Graeme -

What PDF documentation do you use? (Where can I find information on PDF creating?)

Ondrej

Maybe Graeme can comment on the latter, as far as I know, that should work ?

That would be really awesome !

Michael.

Ondrej Pokorny wrote

As is the text width function (for right/center alignment support).

That is already implemented in fpReport (Standard PDF built-in fonts and TTF fonts). What I haven't implemented yet is Font Kerning to make the width calculation even more accurate, but the width difference will be very minor. I can take a look and see if it makes sense to move that code to fpPDF. I'm pretty sure it shouldn't be a problem.

If there is a possibility to render text with custom TTF font in Lazarus (I found easylazfreetype, but I couldn't make it work with my first

I'm not sure if we are talking about the same unit, but the freetype pascal implementation in Lazarus is based on a very old FreeType v1. It also misses tons of features found in the commonly used FreeType v2 library.

I once tried to use the Pascal based FreeType code to reduce dependencies for AggPas text rendering. The Pascal FreeType simply wasn't up to the task and lacked functionality I needed. The fpTTF (font cache) and fpParseTTF (actual TTF data extraction) is much more likely to be successful with my AggPas goal.

I think I'll develop a TPDFDocument->TCanvas renderer for previewing created PDF documents.

Great. I should then be able to plug that into fpReport too. I want to implement a PDF & fpReport -> AggPas renderer too.

Regards,
- Graeme -

Ondrej Pokorny wrote

What PDF documentation do you use? (Where can I find information on PDF creating?)

I used the official PDF v1.3 specification document. All 700 pages of it, which I've probably read a 100 times over now. :)

http://partners.adobe.com/public/developer/en/pdf/PDFReference13.pdf

Regards,
- Graeme -

Giuliano Colla wrote

I'd say that ???????????? ???! is to be preferred, because it has a higher number of characters!

Good point. :)

Regards,
- Graeme -

Please take a look at the code in my email from today 10:09. When I use TFPFontCacheItem.TextWidth, I get this:

(The red rectangle visualizes the textwidth/textheight calculation). The text height is correct, but text width is very different.

We should then try to omit unnecessary double work. I see that AggPas should be able to render TTF fonts already. Why do you need fpTTF and fpParseTTF then? Nevertheless IMO it's good to have as little dependencies as possible, so if the TTF functionality from fp-pdf can be extended to render TTF characters without AggPas, that would be great.

Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160409/46c370e9/attachment.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: facadbbf.png
Type: image/png
Size: 6357 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160409/46c370e9/attachment.png>

Because one of the requirements is not to depend on external libraries. AggPas uses the freetype library to render TTF.

Michael.

Graeme,

If that can be moved to unit fpttf instead of fppdf, then that would be even better.

Michael.

Ondrej Pokorny wrote

P.WriteText(25, 0, 'Sample Text'); // DOESN'T WORK !!!

Indeed. As I mentioned, the Write*Text() names are a bit inaccurate and will be improved. At the moment WriteText() is meant for the Standard PDF Fonts, and WriteUTF8Text() for any TTF fonts used.

I believe here is your mistake. Your system is probably 96 DPI, not 72. If you use gTTFontCache.DPI it would have given you the correct result. At the moment the FontCache object defaults to the most common desktop DPI, which is 96, but in your actual application you can query it with whatever GUI you have and set the value yourself.

Here is verbosely commented code that draws a rectangle around the Page Title text. Screenshot of the output is attached.

==========================
  { draw a rectangle around the Page Title text }
  lPt1.X := 25;  // units in MM
  lPt1.Y := 20;  // units in MM
  lFntPtSize := 23;
  { a rough calculation but not 100% accurate for a specific font. }
//  lTextHeightInMM := ((gTTFontCache.PointSizeInPixels(lFntPtSize) *
25.4) / 72) / 2;
  lFC := gTTFontCache.Find('FreeSans', False, False);
  if not Assigned(lFC) then
    raise Exception.Create('FreeSans font not found');
  lFntInfo := lFC.GetFontData;
  { result is in pixels }
  lHeight := lFntInfo.CapHeight * lFntPtSize * gTTFontCache.DPI / (72 *
lFntInfo.Head.UnitsPerEm);
  { convert pixels to mm as our PDFPage.UnitOfMeasure is set to mm. }
  lTextHeightInMM :=  (lHeight * 25.4) / 72;
  lWidth := lFC.TextWidth('Sample Text', lFntPtSize);
  { convert the Font Units to Millimeters }
  lTextWidthInMM := (lWidth * 25.4) / gTTFontCache.DPI;
  { result is in pixels }
  lHeight := Abs(lFntInfo.Descender) * lFntPtSize * gTTFontCache.DPI /
(72 * lFntInfo.Head.UnitsPerEm);
  { convert pixels to mm as you PDFPage.UnitOfMeasure is set to mm. }
  lDescenderHeightInMM :=  (lHeight * 25.4) / 72;

{ adjust the Y coordinate for the font Descender, because WriteUTF8Text draws on the baseline. }

  lPt1.Y := lPt1.Y + lDescenderHeightInMM;

  P.SetColor(clRed, true);
  P.DrawRect(lPt1.X, lPt1.Y, lTextWidthInMM, lTextHeightInMM, 1, false,
true);
  lFntInfo.Free;
==========================

Regards,
- Graeme -

Graeme Geldenhuys wrote

Here is verbosely commented code that draws a rectangle around the Page Title text.

Apologies, here is the correct code.

=================================
  { Page title }
  P.SetFont(FtText1, 23);
  P.SetColor(clBlack, false);
  P.WriteUTF8Text(25, 20, 'Sample Text');
  { draw a rectangle around the Page Title text }
  lPt1.X := 25;  // units in MM
  lPt1.Y := 20;  // units in MM
  lFntPtSize := 23;
  lFC := gTTFontCache.Find('FreeSans', False, False);
  if not Assigned(lFC) then
    raise Exception.Create('FreeSans font not found');
  lFntInfo := lFC.GetFontData;
  { result is in pixels }
  lHeight := lFntInfo.CapHeight * lFntPtSize * gTTFontCache.DPI /
      (72 * lFntInfo.Head.UnitsPerEm);
  { convert pixels to mm as our PDFPage.UnitOfMeasure is set to mm. }
  lTextHeightInMM :=  (lHeight * 25.4) / gTTFontCache.DPI;
  lWidth := lFC.TextWidth('Sample Text', lFntPtSize);
  { convert the Font Units to Millimeters }
  lTextWidthInMM := (lWidth * 25.4) / gTTFontCache.DPI;
  { result is in pixels }
  lHeight := Abs(lFntInfo.Descender) * lFntPtSize * gTTFontCache.DPI /
      (72 * lFntInfo.Head.UnitsPerEm);
  { convert pixels to mm as you PDFPage.UnitOfMeasure is set to mm. }
  lDescenderHeightInMM :=  (lHeight * 25.4) / gTTFontCache.DPI;
  { adjust the Y coordinate for the font Descender, because
    WriteUTF8Text draws on the baseline. Also adjust the TextHeight
    because CapHeight doesn't take into account the Descender. }
  P.SetColor(clRed, true);
  P.DrawRect(lPt1.X, lPt1.Y+lDescenderHeightInMM, lTextWidthInMM,
      lTextHeightInMM+lDescenderHeightInMM, 1, false, true);
  lFntInfo.Free;

=================================

Regards,
- Graeme -

Graeme Geldenhuys wrote

> As note: If I compile with -Cr, I got a Runerror 201 in unit fpparsettf > >on line 810. I made a note of that, thanks.

The attached patch fixes the range error.

Ondrej
-------------- next part --------------
Index: fpparsettf.pp
=================================================================== --- fpparsettf.pp (revision 33453)
+++ fpparsettf.pp (working copy)
@@ -807,7 +807,8 @@

   FMissingWidth := Widths[Chars[CharCodes^[32]]].AdvanceWidth;  // Char(32) - Space character
   for I:=0 to 255 do
     begin

- if (Widths[Chars[CharCodes^[i]]].AdvanceWidth> 0) and (CharNames^[i] '.notdef') then
+ if (CharCodes^[i]>=0) and (CharCodes^[i]<=High(Chars))
+ and (Widths[Chars[CharCodes^[i]]].AdvanceWidth> 0) and (CharNames^[i] '.notdef') then

       CharWidth[I]:= ToNatural(Widths[Chars[CharCodes^[I]]].AdvanceWidth)
     else
       CharWidth[I]:= FMissingWidth;

IMO it's not about my system DPI (fppdf is headless and doesn't use the GUI DPI). It's the default value in TFPFontCacheList.DPI. Correct? I expected fpttf it to use 72 DPI which is the default for PDF (cDefaultDPI in fppdf.pas). My mistake.

If you use gTTFontCache.DPI it would have given you the correct result.

Indeed, thanks!

At the moment the FontCache object defaults to the most common desktop DPI, which is 96, but in your actual application you can query it with whatever GUI you have and set the value yourself.

Great, thanks Graeme for the code and clarifying, it works! (IMO it would be great to update the example code with "box around text" code. It is a usual task to get text width/height and so you spare your time to clarify it to another person who needs it in the future.)

Ondrej

Wow, let me interfere here before we go in a wrong direction:

The public API should not depend on the selected font.

WriteText() is meant for Ansi text - whatever the current font. WriteUTF8Text() is meant for UTF8 encoded unicode text, whatever the current font.

The user of the API should not have to care what font is used. the API should do whatever is necessary to emit correct PDF for the current font.

If internally there are different calls needed for different fonts, then that is OK, but they should not be exposed to the user, at the best they should be made protected. (if need be, we can expose them later)

If the currently used font does not contain the necessary glyphs to represent the text, we will not check it, that is the responsability of the user.

Michael.

On Sun, Apr 10, 2016 at 3:15 AM, Michael Van Canneyt <

wrote:

It feels like, these two paragraphs:

contradict to:

If the currently used font does not contain the necessary glyphs to represent the text, we will not check it, that is the responsability of the user.

The APIs should either do the font-substitution (with whatever level of control from the user side). (something what graphic APIs are doing for text rendering)
or should not do them at all (leaving full font-substitution to the user)

Then there should be some cross-platform APIs provided (not necessary part of PDF package) that would perform font substitution by the (unicode) text and the desired font (font-size).

Eventually, someone would provide WriteUTF8TextSmart() function, that would split the text into parts (by fonts used) and would populate the PDF accordingly, if PDF library doesn't the font-substitution itself.

For example, rendering a text with mix of latin letters and hieroglyphs, using Times New Roman font. Typically for hieroglyphs one of system default CJK fonts are used.

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160410/fe01b30e/attachment.html>

No, why ? One is about encoding of the supplied text.

The other about whether the current font has the necessary glyphs to render the text.

The APIs should either do the font-substitution (with whatever level of control from the user side). (something what graphic APIs are doing for text rendering) or should not do them at all (leaving full font-substitution to the user)

The latter. KISS (keep it simple, stupid) is my motto.

Font substitution is a potentially huge subject.
I would not want this in the initial low-level API.

But I agree with you that additional apis for this can be very useful and should be put on the todo list.

Michael.

Michael Van Canneyt wrote

Wow, let me interfere here before we go in a wrong direction: The public API should not depend on the selected font.

I know. The current implementation gravitated towards the situation we have now, but that is definitely not how it is going to end up. Like I mentioned in one of my earlier replies, we will end up with overloaded WriteText() calls only, and internally the fpPDF code will sort out what font code to generate. Up to now, one of my high priority was figuring out font embedding and handling of ASCII and Unicode text - this task seems complete (except for the Unicode range above BMP which still needs some minor attention).

These should all be addressed in the next round of updates.

Regards,
- Graeme -

OK, seems we are of the same mind, I just wanted to make sure of that :-)

Michael.

On Sun, Apr 10, 2016 at 4:23 AM, Michael Van Canneyt <

I see the issue now. It's in my perception of PDF format. I always assumed it represents text as a sequence of glyphs, rather than sequence of characters. But it seems like both options are possible.

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160410/c1ea6aad/attachment.html>

Michael Van Canneyt wrote

Font substitution is a potentially huge subject. I would not want this in the initial low-level API.

Indeed. The *nix libXft.so library with combination of FontConfig does this for general desktop applications, but it is a huge task. Windows doesn't do font substitution at all for desktop applications.

As for PDFs, the problem is handled in two ways as per the official PDF spec.

1) if you embed a font, but the character glyphs do not exist for that font, you use GlyphID 0, which should draw a rectangle in place of the glyph.

2) if you don't embed a TTF font, all the font information will still be written to the PDF. The PDF viewer (no matter the platform) can then try and use the exact font, if it is available on the current system. If not, the PDF viewer uses the font information to substitute it with a font from the same family.

Both cases are already implemented in fpPDF.

Regards,
- Graeme -

Dmitry Boyarintsev wrote

I always assumed it represents text as a sequence of glyphs, rather than sequence of characters. But it seems like both options are possible.

No, your first assumption is correct. When it comes to PDF, there is NO notion of text strings (sequence of characters). PDF only understands graphical elements (lines, rectangles, curves etc). The PDF creator breaks text down into character ID's (something like Unicode codepoints
- but again PDF's know nothing about Unicode either). Those character ID's are used to look up Glyph ID's in the font file. The Glyph ID's are what are stored inside the PDF. When viewed, those glyph ID's are used to retrieve the vector graphic instructions from the font file to render a glyph.

You might view a PDF with a text editor and see text strings. It might look like text strings to you (eg: ASCII range), but PDF doesn't consider them text, but rather ID's. It is pure coincidence that they happen to look like text in a text editor.

Regards,
- Graeme -

You've got a bug in the font height functions. They must not be scaled with ToNatural.

Try e.g. the Tahoma font from Windows or any other font where FHead.UnitsPerEm1000. You'll see wrong results.

Your example works because FHead.UnitsPerEm is 1000 for your version of FreeSans. If you use an old FreeSans where UnitsPerEm is 2048, you get wrong box height.

I needed about 2 hours to find it :(

See http://mantis.freepascal.org/view.php?id=30008

Ondrej

Ondrej Pokorny wrote

You've got a bug in the font height functions. They must not be scaled with ToNatural.

Well done Ondrey, you are indeed correct. Amazing, because the example code I posted was tested with four other fonts. Incidently they all had the same UnitsPerEm, so the issue went unnoticed.

Regards,
Graeme