bugThe FreeType Project - Bugs: bug #47582, Font size is rounded

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #47582: Font size is rounded

Submitted by:  Kouhei Sutou <kou>
Submitted on:  Thu 31 Mar 2016 10:10:42 AM UTC  
 
Severity:  3 - Normal Item Group:  Incorrect behaviour
Status:  Invalid Privacy:  Public
Assigned to:  Werner LEMBERG <wl> Open/Closed:  Closed
Planned Release:  None

( Jump to the original submission)

Fri 01 Apr 2016 10:17:33 AM UTC, comment #9: 

> You provided a simple demo C program to show what you believe is a bug. This is perfect: The smaller such a program, the better of course, and C is indeed the best language to use.


OK. I'll use C.

> I've replied that I think that there isn't a bug, and that a high-level library like Pango can better handle the issue, this is, creating a PDF that properly scales a font without `steps'. In particular, (a) the font metrics shouldn't be derived from hinted font instances, and (b) linear advance widths must be used everywhere. Note that I haven't actually tried this; it is rather an educated guess since I'm not familiar with either Cairo or Pango.


Thanks for the information. I'm going to send a question to cairo's mailing list.

> Do you still think that there is a bug in FreeType?


No I don't.

Kouhei Sutou <kou>
Thu 31 Mar 2016 06:21:45 PM UTC, comment #8: 

Just a moment –  Maybe I've completely misunderstood your intentions!

You provided a simple demo C program to show what you believe is a bug.  This is perfect: The smaller such a program, the better of course, and C is indeed the best language to use.

I've replied that I think that there isn't a bug, and that a high-level library like Pango can better handle the issue, this is, creating a PDF that properly scales a font without `steps'.  In particular, (a) the font metrics shouldn't be derived from hinted font instances, and (b) linear advance widths must be used everywhere.  Note that I haven't actually tried this; it is rather an educated guess since I'm not familiar with either Cairo or Pango.

Do you still think that there is a bug in FreeType?

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Thu 31 Mar 2016 02:32:03 PM UTC, comment #7: 

> BTW, it is completely irrelevant whether we `like' less dependencies or not...


OK. I'll attach a program that is written by Ruby and Ruby bindings of Pango at the next bug report. I always use them to use FreeType. They provide higher-level API.

Kouhei Sutou <kou>
Thu 31 Mar 2016 10:53:48 AM UTC, comment #6: 

Well, FreeType is a library to render glyphs, nothing more; it simply doesn't provide a sophisticated text layout API.  In other words, you must use a higher-level library for text layout if you don't want to write the code by yourself.

BTW, it is completely irrelevant whether we `like' less dependencies or not...

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Thu 31 Mar 2016 10:47:32 AM UTC, comment #5: 

> According to http://cairographics.org/FAQ/#using_pango you should use pango instead of the very limited Cairo text API.


I usually use Pango. I used the cairo text API for the program because it reduces dependencies. I thought that FreeType developers like less dependencies.

Kouhei Sutou <kou>
Thu 31 Mar 2016 10:44:30 AM UTC, comment #4: 

Thanks for your answer. I understand that this is the expected behavior.

Kouhei Sutou <kou>
Thu 31 Mar 2016 10:43:15 AM UTC, comment #3: 

According to http://cairographics.org/FAQ/#using_pango you should use pango instead of the very limited Cairo text API.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Thu 31 Mar 2016 10:33:54 AM UTC, comment #2: 

It is expected.  To be more precise, the PPEM value (this is the same as the font size at 72dpi) can only be an integer value if you are using the TrueType hinter.

The same is basically true for FreeType's auto-hinter also, since the job is the same, namely to align glyphs to the pixel grid.

Please send further questions to the `freetype' mailing list, which is a far better forum than a bug report.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Thu 31 Mar 2016 10:13:41 AM UTC, comment #1: 

Oh...
The program and diff are broken...

I attach the program and diff. Please refer them.

(file #36806, file #36807)

Kouhei Sutou <kou>
Thu 31 Mar 2016 10:10:42 AM UTC, original submission:  

I don't know whether this behavior is a FreeType bug or not but I'll report it.

The specified font size of scaled TrueType font (e.g. DejaVu Sans Mono: http://dejavu-fonts.org/ ) is rounded. For example, all of font sizes between 8.5 * 64 and 9.499... * 64 are the same.

Here is a C program that reproduces this behavior (Sorry. This uses cairo.):

<pre>
/* gcc -o truetype-size truetype-size.c $(pkg-config --cflags --libs cairo-pdf) */

#include &lt;stdio.h&gt;
#include &lt;cairo.h&gt;
#include &lt;cairo-pdf.h&gt;

int
main(void)
{
  cairo_surface_t *surface;

  surface = cairo_pdf_surface_create("truetype-size.pdf", 250, 250);
  {
    cairo_t *cr;
    double font_size;
    double y = 0.0;

    cr = cairo_create(surface);
    /* Select scalable TrueType font */
    /* DejaVu fonts: http://dejavu-fonts.org/ */
    cairo_select_font_face(cr,
                           "DejaVu Sans Mono",
                           CAIRO_FONT_SLANT_NORMAL,
                           CAIRO_FONT_WEIGHT_NORMAL);
    for (font_size = 8.0; font_size &lt;= 10; font_size += 0.125) {
      char font_size_text[128];

      y += 10.0;

      /* Render font size */
      cairo_set_font_size(cr, 8.0);
      cairo_move_to(cr, 0.0, y);
      snprintf(font_size_text, 128, "%.3f", font_size);
      cairo_show_text(cr, font_size_text);

      /* Render text */
      cairo_set_font_size(cr, font_size);
      cairo_move_to(cr, 35.0, y);
      cairo_show_text(cr, "abcdefghijklm");
    }
    cairo_destroy(cr);
  }
  cairo_surface_finish(surface);
  cairo_surface_destroy(surface);

  return 0;
}
</pre>

See the first line how to build this program. This program outputs "truetype-size.pdf" to the current directory.

I'll attach two PDFs. One is generated by the current master ( http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=fb550bf4666586eedf840f7331c4796ad0739f1d ). Another is generated with the following change with the current master:

<pre>
diff --git a/src/truetype/ttdriver.c b/src/truetype/ttdriver.c
index bbebabd..39b0e78 100644
--- a/src/truetype/ttdriver.c
+++ b/src/truetype/ttdriver.c
@@ -311,7 +311,7 @@
     if ( FT_IS_SCALABLE( size-&gt;face ) )
     {
       error = tt_size_reset( ttsize );
-      ttsize-&gt;root.metrics = ttsize-&gt;metrics;
+      /* ttsize-&gt;root.metrics = ttsize-&gt;metrics; */
     }

     return error;
</pre>

Could you confirm whether the current behavior (8 * 64 to 9.49... * 64 are treated as the same size) is expected or not?

Kouhei Sutou <kou>

 

Attached Files
file #36806:  truetype-size.c added by kou (1KiB - text/x-csrc)
file #36807:  revert-b0962ac3.diff added by kou (389B - text/x-diff)
file #36804:  truetype-size-without-patch.pdf added by kou (8KiB - application/pdf)
file #36805:  truetype-size-with-patch.pdf added by kou (8KiB - application/pdf)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by kou (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-03-31 wl StatusNone => Invalid
        Assigned toNone => wl
        Open/ClosedOpen => Closed
    2016-03-31 kou Attached File- => Added truetype-size.c, #36806
        Attached File- => Added revert-b0962ac3.diff, #36807
    2016-03-31 kou Attached File- => Added truetype-size-without-patch.pdf, #36804
        Attached File- => Added truetype-size-with-patch.pdf, #36805

    Back to the top


    Powered by Savane 3.6