Text Rendering on PDF Export

PolomintPolomint Australia
edited 10:58AM in FastReport VCL 5
FYI - I have raised a ticket #330883 because sometime between release 5.3.6 and 5.3.9 the rendering of text on reports by the Export To PDF function has changed.

Reports appear correct in FR Preview Window, but in the PDF file produced by the export fields are truncated on the right-hand side.

May have to revert to v5.3.6 until this is fixed :-(

Comments

  • PolomintPolomint Australia
    edited 10:58AM
    Paul G tells me that this is a "known problem" and that it is being worked on.

    Standing by... >
  • PolomintPolomint Australia
    edited 10:58AM
    v5.3.11 does not fix this problem sadly. I thought the following bullet-points in the Changes.txt file with the update were promising, but no such luck!

    - Fixed style simulation for Arial Narrow, Arial Unicode MS and Tahoma fonts in the TfrxPDFExport
    - Fixed width of monospace font if it embedded into PDF document
    - Fixed style simulation for Arial Black font in the TfrxPDFExport
    - Fixed CharSpacing > 0 error for haRight alignment in the PDF export

    As far as I can see this has made no difference to any of my reports >
  • gpigpi
    edited 10:58AM
    wrote:
    v5.3.11 does not fix this problem sadly. I thought the following bullet-points in the Changes.txt file with the update were promising, but no such luck!

    - Fixed style simulation for Arial Narrow, Arial Unicode MS and Tahoma fonts in the TfrxPDFExport
    - Fixed width of monospace font if it embedded into PDF document
    - Fixed style simulation for Arial Black font in the TfrxPDFExport
    - Fixed CharSpacing > 0 error for haRight alignment in the PDF export

    As far as I can see this has made no difference to any of my reports sad.gif

    After this fix

    - Fixed width of monospace font if it embedded into PDF document

    your error was appear
  • PolomintPolomint Australia
    edited 10:58AM
    gpi wrote: »
    After this fix

    - Fixed width of monospace font if it embedded into PDF document

    your error was appear
    I am sorry, I don't understand your response. The rendering of text by the PDF export in v5.3.11 is not the same as the preview window. None of the fonts I use in my reports are "monospaced" (Tahoma, Calibri etc.).

    FastReports was correctly rendering text in PDF exports in versions before (and including) v5.3.6.
  • gpigpi
    edited 10:58AM
    The rendering of text by the PDF export in v5.3.11 is not the same as the preview window. None of the fonts I use in my reports are "monospaced" (Tahoma, Calibri etc.).
    
    FastReports was correctly rendering text in PDF exports in versions before (and including) v5.3.6.
    
    Yes, this problem was appear after this fix:

    - Fixed width of monospace font if it embedded into PDF document

    You may use FR 5.3.6 or modify frxTrueTypeFont.pas
    procedure TrueTypeFont.BuildGlyphIndexList(used_glyphs: TList; uniscribe: boolean; decompose: boolean; collate: boolean; use_kerning: boolean );
    var
    location: Cardinal;
    composed_idx: Word;
    i, j, length, GlyphWidth: Integer;
    key, idx, next_idx: Word;
    hash_index: Cardinal;
    composed_indexes: TIntegerlist;
    new_key, kerning: Smallint;
    begin
    Indices := TIntegerList.Create;
    i := 0;
    while ((i < used_glyphs.Count)) do
    begin
    key := Word(used_glyphs[i]);
    if uniscribe then idx := key else idx := self.cmap_table.GetGlyphIndex(key);
    length := self.index_to_location.GetGlyph(idx, self.font_header, location);
    if (length <> 0) then
    begin
    composed_indexes := self.glyph_table.CheckGlyph(Cardinal(location), length);
    for j := 0 to composed_indexes.Count - 1 do
    begin
    composed_idx := Word(composed_indexes[j]);
    new_key := Indices.IndexOf(Pointer(composed_idx));
    if (not collate or (decompose and (new_key = -1))) then begin
    Indices.Add( Pointer(composed_idx));
    if idx < self.horizontal_metrix_table.NumberOfMetrics then
    GlyphWidth := ((self.horizontal_metrix_table.Item[idx].advanceWidth * $3e8) div self.font_header.unitsPerEm)
    else
    GlyphWidth := (self.windows_metrix.AvgCharWidth * $3e8) div self.font_header.unitsPerEm;
    GlyphWidths.Add(Pointer(GlyphWidth))
    end;
    end;
    if (not collate or (Indices.IndexOf(Pointer(idx)) = -1)) then
    begin
    Indices.Add( Pointer(idx));
    if idx < self.horizontal_metrix_table.NumberOfMetrics then
    GlyphWidth := ((self.horizontal_metrix_table.Item[idx].advanceWidth * $3e8) div self.font_header.unitsPerEm)
    else
    GlyphWidth := (self.windows_metrix.AvgCharWidth * $3e8) div self.font_header.unitsPerEm;
    if (use_kerning and ((i < (used_glyphs.Count - 1)) and (self.kerning_table <> nil))) then
    begin
    new_key := Word(used_glyphs[i + 1]);
    if uniscribe then next_idx := new_key else next_idx := self.cmap_table.GetGlyphIndex(new_key);
    hash_index := Cardinal(idx or (next_idx shl $10));
    kerning := self.kerning_table.Item[hash_index];
    inc(GlyphWidth, ((kerning * $3e8) div self.font_header.unitsPerEm))
    end;
    GlyphWidths.Add(Pointer(GlyphWidth))
    end;
    composed_indexes.Free;
    end
    else
    begin
    new_key := Indices.IndexOf(Pointer(idx));
    if new_key = -1 then
    begin
    Indices.Add(Pointer(idx));
    if key <> $667 then
    begin
    if idx < self.horizontal_metrix_table.NumberOfMetrics then
    j := ((self.horizontal_metrix_table.Item[idx].advanceWidth * $3e8) div self.font_header.unitsPerEm)
    else
    j := (self.windows_metrix.AvgCharWidth * $3e8) div self.font_header.unitsPerEm;
    end
    else
    j := 0;
    GlyphWidths.Add(Pointer(j))
    end;
    end;
    inc(i)
    end;
    end;
    
  • PolomintPolomint Australia
    edited 10:58AM
    CLOSED [img]style_emoticons/<#EMO_DIR#>/biggrin.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin.gif" /> FR v5.3.12 has fixed the text rendering problems we had with exporting to PDF (at least in the limited testing we have done today). I've also noted that a problem we had with "extended characters" such as the Indian Rupee symbol has now been fully resolved (at least in the PDF file), so I am hopeful that further testing of our suite of reports will be equally satisfactory. And I didn't have to revert to v5.3.6 to meet our deadline![/img]

Leave a Comment