bugThe FreeType Project - Bugs: bug #58798, Curve about to intersect pixel

 
 

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

bug #58798: Curve about to intersect pixel

Submitter:  - <_194785>
Submitted:  Tue 21 Jul 2020 12:27:14 PM UTC
   
 
Severity:  3 - Normal Item Group:  None
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Planned Release:  None

Jump to the original submission

Thu 19 Nov 2020 07:32:24 AM UTC, comment #13: 


comment #12:

> Here is the answer: The interpolated points are rounded up in the 26.6 space!


After doing that, the second glitching reveals itself in the Ē glyph, which should not have a filled pixel with the rounded up interpolated points.

Anonymous
Thu 19 Nov 2020 07:06:40 AM UTC, comment #12: 

Here is the answer: The interpolated points are rounded up in the 26.6 space!

Anonymous
Mon 16 Nov 2020 09:48:26 PM UTC, comment #11: 


comment #10:

> You attached a wrong test font:
> (1) no glyph aligns with pixel centers at the extrema,
> (2) a testing ppem seems to be 1024,
> (3) OS/2 table is lazily incomplete, i.e. non-portable.
>
> Please attach correct file.


No, it's correct.

The (1) is how FreeType interprets it and that's exactly the bug. In GDI it works properly.
In (2) the ppem is supposed to be 16.
In (3) this is deliberate. Because the font is meant to be run in a formal renderer environment not a lazily made implementation.

Anonymous
Wed 30 Sep 2020 03:03:39 AM UTC, comment #10: 

You attached a wrong test font:
(1) no glyph aligns with pixel centers at the extrema,
(2) a testing ppem seems to be 1024,
(3) OS/2 table is lazily incomplete, i.e. non-portable.

Please attach correct file.

Alexei Podtelezhnikov <podtelez>
Group Member
Fri 14 Aug 2020 04:26:47 PM UTC, comment #9: 


> I do have autism


OK, everything is clear now.

> and you still haven't told me what FreeType
> settings reproduce your uncomfortable text problem.

 
My response wasn't meant literally.  Let me reformulate it to make it easier for you to understand: Most developers get uncomfortable feelings while reading your responses, since the responses look like attacks.  The problem I was writing about in my previous comment is thus not related to 'technical settings' but the way and style how you write remarks and responses.

Again: if you want to successfully communicate with developers, try to provide factual reports without adding criticism!  If you replace criticism with suggestions for improvements, everything will certainly appear much more friendly to the eyes of other people.  Maybe it doesn't make a difference for you, but everybody else will benefit.

Werner LEMBERG <wl>
Group administrator
Fri 14 Aug 2020 03:55:38 PM UTC, comment #8: 


comment #7:

> >> Fact is that you demand stuff from FreeType developers,
> >> mostly in words that are very uncomfortable to read.
> >
> > I think I know why they are very uncomfortable to read,
> > because of FreeType rendering! Have you tried changing
> > FreeType settings to make the text more comfortable to
> > read? What are your FreeType settings that reproduce
> > uncomfortable text?
>
> You are either intentionally misunderstanding what I write, or you are really not able to get my point due to, say, some form of autism: I mean the social implications of your comments.
>


I do have autism and you still haven't told me what FreeType settings reproduce your uncomfortable text problem.

comment #7:

> Nobody wants to work with persons who are continuously either insulting the developers or bashing their software.  You do both.  As soon as you stop that, doing factual reports, chances are good that you get a serious discussion.
>
> If you don't see what's wrong with your comments, please ask a friend for help to check your messages before posting.


What you think about it has nothing to do with Curve about to intersect pixel. If you continue to miss the point of bilevel glitchings, TD renderer might start becoming increasingly more accurate than FreeType.

- <_194785>
Fri 14 Aug 2020 03:01:08 PM UTC, comment #7: 


>> Fact is that you demand stuff from FreeType developers,
>> mostly in words that are very uncomfortable to read.
>
> I think I know why they are very uncomfortable to read,
> because of FreeType rendering! Have you tried changing
> FreeType settings to make the text more comfortable to
> read? What are your FreeType settings that reproduce
> uncomfortable text?


You are either intentionally misunderstanding what I write, or you are really not able to get my point due to, say, some form of autism: I mean the social implications of your comments.

Nobody wants to work with persons who are continuously either insulting the developers or bashing their software.  You do both.  As soon as you stop that, doing factual reports, chances are good that you get a serious discussion.

If you don't see what's wrong with your comments, please ask a friend for help to check your messages before posting.

Werner LEMBERG <wl>
Group administrator
Fri 14 Aug 2020 12:32:23 PM UTC, comment #6: 


comment #5:

> Fact is that you demand stuff from FreeType developers, mostly in words that are very uncomfortable to read.


I think I know why they are very uncomfortable to read, because of FreeType rendering! Have you tried changing FreeType settings to make the text more comfortable to read? What are your FreeType settings that reproduce uncomfortable text?


comment #5:

> A final remark to the 'glitches': It is very hard to properly emulate the MS rasterizer.  Essentially, what FreeType does is in most cases exactly what the OpenType specification says.  In other words, FreeType is not wrong.  However, it sometimes doesn't produce the same results.  It is a very big problem of the OpenType specification that it leaves so much room for interpretation, especially w.r.t. rounding.  Bad, bad, bad.


No, it's not the problem of the OpenType specification. It is entirely deliberate that the Microsoft bilevel renderer is proprietary and undocumented. How else do you expect Microsoft profit from TrueType rendering (even before ClearType was introduced with even more things that could go wrong)?


comment #5:

> The normal way is that there is an unambiguous standard together with a reference implementation that people can study and implement.  We don't have that for OpenType.


Of course, that's because the actual details of the Microsoft bilevel renderer are proprietary to Microsoft! The bilevel renderer is one of the very very many reasons Microsoft does not upload the source code of Microsoft Windows. Why would the OpenType people make a reference implementation that would allow anyone to imitate TrueType rendering?

comment #5:

> It's definitely not fun to reverse-engineer the MS B/W TrueType engine and rasterizer to catch corner cases.  This needs time and interest.  Right now, there is nobody who has enough time and interest.  Of course, this is not ideal, but that's life.




[comment #5 comment #5:

> As Alexei said: If you are interested to see fixes, please get acquainted with the FreeType sources and try to contribute!  You are able to write and read C code.


That's not how code works, I did not write the rasterizer so I have no idea what it is doing! The code is expressing their writer's impressions of what a TrueType rasterizing algorithm would look like, which is completely different from what I think a TrueType rasterizing algorithm looks like (which is reflected in the competing TD renderer rasterizer) so it's impossible for me to know where the glitchings happen. If you were to attempt to contribute to TD renderer, you would for sure not be able to do it.

- <_194785>
Fri 14 Aug 2020 07:59:25 AM UTC, comment #5: 

Thanks for the details, it is helpful.

> So you're saying Alexei worships FreeType as if it had no
> bugs whatsoever.


Where do I write this?  This is your interpretation of my words, and it is wrong.  Fact is that you demand stuff from FreeType developers, mostly in words that are very uncomfortable to read.  Instead of stating facts in a quiet, factual manner you use a lot of aggressive words like 'clearly', 'extremely', 'disappointing', 'in the slightest', etc., etc.  Such words and phrases do *not* belong to bug reports!  Even if you are right (and you are) it makes developers ignore you completely, for personal reasons.  No idea how you behave in real life, but if you do that to others you might expect rejection elsewhere, too.

A final remark to the 'glitches': It is very hard to properly emulate the MS rasterizer.  Essentially, what FreeType does is in most cases exactly what the OpenType specification says.  In other words, FreeType is not wrong.  However, it sometimes doesn't produce the same results.  It is a very big problem of the OpenType specification that it leaves so much room for interpretation, especially w.r.t. rounding.  Bad, bad, bad.

The normal way is that there is an unambiguous standard together with a reference implementation that people can study and implement.  We don't have that for OpenType.

It's definitely not fun to reverse-engineer the MS B/W TrueType engine and rasterizer to catch corner cases.  This needs time and interest.  Right now, there is nobody who has enough time and interest.  Of course, this is not ideal, but that's life.  As Alexei said: If you are interested to see fixes, please get acquainted with the FreeType sources and try to contribute!  You are able to write and read C code.

Werner LEMBERG <wl>
Group administrator
Fri 14 Aug 2020 07:25:19 AM UTC, comment #4: 


comment #3:

> Ah, I really missed that the images are so small.  Thanks for uploading.
>
> However, you still don't say on which platform you've created your images, and how!  What exactly is the `proper TrueType renderer` you are mentioning?  In particular, what Windows version are you using?
>
> And how did you create the FreeType rendering results?  Which program did you use?  What command line options, what key presses?  How was it captured, etc., etc.
>
> All of this is essential to reproduce and test the results.  It might appear trivial to you, but it isn't.
>
> Note that your comment about 'FreeType is clearly an inaccurate renderer' is (a) impertinent – it is this kind of unnecessary side remarks that Alexei is calling 'trolling' –, and (b) completely wrong.  It's rather vice versa: the Windows B/W renderer uses a certain 16bit, non-standard way of rounding that all implementations have to emulate, and which is completely undocumented.


The proper TrueType renderer is of course the Microsoft bilevel renderer, and I have been using Microsoft Notepad on Windows 7 to reproduce the correct rendering.

As for the FreeType reproduction, typing
ĀāĂ㥹ĆćĈĉ
ĊċČčĎďĐđĒē
ĔĕĖėĘęĚěĜĝ
ĞğĠġĢģĤĥĦħ
ĨĩĪīĬĭĮįİı
IJijĴĵĶķĸĹĺĻ
ļĽľĿŀŁłŃńŅ
ņŇňʼnŊŋŌōŎŏ
ŐőŒœŔŕŖŗŘř
ŚśŜŝŞşŠšŢţ
in the FreeType font preview will reproduce the incorrect rendering.

So you're saying Alexei worships FreeType as if it had no bugs whatsoever. Which is not quite the right behavior for a bug reporting website! What's the point of a bug report website if all bugs are invalid? They aren't!

It is not completely wrong at all. It is exactly that all implementations have to emulate, and it is evident that FreeType does not properly do so in the slightest as seen by a lot of glitching, and not properly simulating TrueType rendering makes it an inaccurate renderer because it is. No wonder the Microsoft bilevel renderer remained the same throughout! Because it didn't have to change, not that it ever could! That makes FreeType an inaccurate renderer because it does not represent the type designer's intent as for instance is properly shown in Visual TrueType which uses the Microsoft bilevel renderer. The reason it's undocumented is because the Microsoft bilevel renderer is intentionally proprietary!

- <_194785>
Fri 14 Aug 2020 03:17:56 AM UTC, comment #3: 

Ah, I really missed that the images are so small.  Thanks for uploading.

However, you still don't say on which platform you've created your images, and how!  What exactly is the `proper TrueType renderer` you are mentioning?  In particular, what Windows version are you using?

And how did you create the FreeType rendering results?  Which program did you use?  What command line options, what key presses?  How was it captured, etc., etc.

All of this is essential to reproduce and test the results.  It might appear trivial to you, but it isn't.

Note that your comment about 'FreeType is clearly an inaccurate renderer' is (a) impertinent – it is this kind of unnecessary snide remarks that Alexei is calling 'trolling' –, and (b) completely wrong.  It's rather vice versa: the Windows B/W renderer uses a certain 16bit, non-standard way of rounding that all implementations have to emulate, and which is completely undocumented.

So please don't make this kind of unobjective, personal comments that annoy all of us.

Werner LEMBERG <wl>
Group administrator
Wed 12 Aug 2020 01:15:54 PM UTC, comment #2: 

comment #1:

> Some of the links are broken, showing no image.  Please upload all relevant images to this bug report.
>
> Additionally, please give exact information on how you created the images.  In particular, since FreeType tries to emulate Windows rendering, we need all the gory details that allows us to reproduce the issue if necessary.  All 'should render like this' cases must be backed up with images that use the Windows TrueType rendering stack.
>
> BTW, a nice solution to get such images is Microsoft's VTT program.


No, the links are working. Maybe if you stop using overly high resolution screens you would see the 10×10 images.

o5W4gGd is the image showing the proper TrueType renderer. Four pixels on the edges are in the outline as seen in fIjB3sX , however FreeType incorrectly renders cE5Wf2l .

To render and reproduce, use the bilevel renderer in FreeType, use the attached font specifically at 16ppem, and render the following multiline string:

ĀāĂ㥹ĆćĈĉ
ĊċČčĎďĐđĒē
ĔĕĖėĘęĚěĜĝ
ĞğĠġĢģĤĥĦħ
ĨĩĪīĬĭĮįİı
IJijĴĵĶķĸĹĺĻ
ļĽľĿŀŁłŃńŅ
ņŇňʼnŊŋŌōŎŏ
ŐőŒœŔŕŖŗŘř
ŚśŜŝŞşŠšŢţ


- <_194785>
Wed 12 Aug 2020 03:20:08 AM UTC, comment #1: 

Some of the links are broken, showing no image.  Please upload all relevant images to this bug report.

Additionally, please give exact information on how you created the images.  In particular, since FreeType tries to emulate Windows rendering, we need all the gory details that allows us to reproduce the issue if necessary.  All 'should render like this' cases must be backed up with images that use the Windows TrueType rendering stack.

BTW, a nice solution to get such images is Microsoft's VTT program.

Werner LEMBERG <wl>
Group administrator
Tue 21 Jul 2020 12:27:14 PM UTC, original submission:  

Ok so I made a testing font equivalent to each point of this shape: https://i.imgur.com/fIjB3sX.png

The test string is multiline, and is as following:

ĀāĂ㥹ĆćĈĉ
ĊċČčĎďĐđĒē
ĔĕĖėĘęĚěĜĝ
ĞğĠġĢģĤĥĦħ
ĨĩĪīĬĭĮįİı
IJijĴĵĶķĸĹĺĻ
ļĽľĿŀŁłŃńŅ
ņŇňʼnŊŋŌōŎŏ
ŐőŒœŔŕŖŗŘř
ŚśŜŝŞşŠšŢţ

What does this render in TrueType? It should render like this: https://i.imgur.com/o5W4gGd.png

However, FreeType is clearly an inaccurate renderer as evidenced by many glitches. One of them is Curve about to intersect pixel, and therefore it incorrectly renders like this: https://i.imgur.com/cE5Wf2l.png

Four glyphs, namely ąĨış apparently intersect the middle of the pixel as well therefore should go in. FreeType however glitches out.

The TrueType bilevel renderer is extremely important, and the glitching of FreeType is extremely disappointing and unusable for the purposes of software preservation.

- <_194785>

 

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

Attached Files
file #49657:  fIjB3sX.png added by _194785 (17KiB - image/png)
file #49658:  cE5Wf2l.png added by _194785 (86B - image/png)
file #49659:  o5W4gGd.png added by _194785 (96B - image/png)
file #49527:  interpolatedtest.ttf added by _194785 (5KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by podtelez (Posted a comment)
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by _194785 (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-08-14 wl StatusNeed Info None
    2020-08-12 _194785 Attached File- Added fIjB3sX.png, #49657
        Attached File- Added cE5Wf2l.png, #49658
        Attached File- Added o5W4gGd.png, #49659
    2020-08-12 wl StatusNone Need Info
    2020-07-21 _194785 Attached File- Added interpolatedtest.ttf, #49527

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code