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

Submitter:  Kouhei Sutou <kou>
Submitted:  Thu 31 Mar 2016 10:10:42 AM UTC
   
 
Severity:  3 - Normal Item Group:  Incorrect behaviour
Status:  Invalid Privacy:  Public
Assigned to:  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>
Group administrator
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>
Group administrator
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>
Group administrator
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>
Group administrator
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>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    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.13-d3ae.
    Corresponding source code