bugThe FreeType Project - Bugs: bug #58373, Half pixel glitching

 
 

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

bug #58373: Half pixel glitching

Submitted by:  - <_194785>
Submitted on:  Fri 15 May 2020 01:29:11 PM UTC
 
Severity:  1 - Wish Item Group:  Incorrect behaviour
Status:  Ready For Test Privacy:  Public
Assigned to:  None Open/Closed:  Open
Planned Release:  2.10.3
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       No canned response available

 

( Jump to the original submission )

Tue 17 Nov 2020 08:53:02 PM UTC, comment #41: 

While VCPB does save processing power in the rendering phase compared to SPPB, it also introduces a similar amount of processing power overhead in the outline generation phase required to generate virtual coordinates and vertical extrema, cancelling out the performance. However, it is still worth it considering the rendering accuracy improvements it has.

Anonymous
Mon 16 Nov 2020 09:41:19 PM UTC, comment #40: 

As TD renderer gets updated, it starts to develop complexity and performance issues.

FreeType 2.10.2: 35.772s
TD renderer 1.0: 32.610s
TD renderer 2.0: 42.356s
TD renderer 3.0: 50.820s

Therefore, Type Design is working on making a more efficient pixel building method than Six Pass Pixel Building (SPPB). It would rely on virtual coordinates where rounding is dependent on consecutive points to determine the render bounds of each bezier to correctly render half pixels, and the pixel building method would be named Virtual Coordinates Pixel Building (VCPB).

Anonymous
Wed 11 Nov 2020 07:32:26 PM UTC, comment #39: 

Riglos Mono 1.4 has deliberate incompatibility and counterclockwise rectangles on half pixel outlines are a part of that incompatibility.

Half pixel glitching — counterclockwise rectangles in deliberate incompatibility.PNG shows the glitching that occurs. In odd ppem sizes, the counterclockwise rectangles fall on half pixels. The classic GDI renderer, as well as the ClearType GDI renderer, in fact any Microsoft renderer, and TD renderer, correctly round the half pixels towards background. FreeType 2.10.2 due to Half pixel glitching incorrectly rounds the half pixels towards the negative space. Half pixels are rounded up, not away from zero. In fact, FreeType has to go out of its way to round away from zero, so fixing this would in fact improve performance due to avoiding having to check for winding.


Anonymous
Sat 26 Sep 2020 05:52:13 PM UTC, comment #38: 

Discuss what the best Quadratic Formula for Pixel Building is at https://pixelbuilding.createaforum.com/quadratic-pixel-building/quadratic-formula/

Using the wrong Quadratic Formula can lead to glitching including Half pixel glitching

Anonymous
Mon 21 Sep 2020 06:36:02 AM UTC, comment #37: 

comment #36:

> Piotr,
>
> The ultimate goal is to produce legible text that is pleasant to read. Therefore, I only care that good fonts work well with FreeType. If you intentionally break conventions (wrong contour orientation, degenerate superimposed segments, etc) to show some weird behavior in GDI or FreeType, I am going to ignore it because these are not real fonts. Every font designer knows that you are asking for trouble if you break conventions. Rendering weird shapes using bilevel rasterizer does not bring you closer to the ultimate goal.
>


You never know, there may be hinted outlines out there that rely on inside out half pixels to work properly. TD renderer 3.0 had to introduce special hacks for missing extrema because many hinted glyphs relied on them to render as the type designer intended. Taking Rule 2 literally only adds unnecessary complexity to the renderer for what the Microsoft renderer doesn't do. Please implement Six Pass Pixel Building, as it is the only method known to work properly.

> Please show discrepancies using good fonts or at least reasonable and well-defined shapes. Ok?
>
>
>


Are you serious? Nobody would buy a license for core fonts just to reproduce an issue. It is much better to use free fonts to demonstrate issuing.

Anonymous
Sun 20 Sep 2020 07:07:01 PM UTC, comment #36: 

Piotr,

The ultimate goal is to produce legible text that is pleasant to read. Therefore, I only care that good fonts work well with FreeType. If you intentionally break conventions (wrong contour orientation, degenerate superimposed segments, etc) to show some weird behavior in GDI or FreeType, I am going to ignore it because these are not real fonts. Every font designer knows that you are asking for trouble if you break conventions. Rendering weird shapes using bilevel rasterizer does not bring you closer to the ultimate goal.

Please show discrepancies using good fonts or at least reasonable and well-defined shapes. Ok?

Alexei Podtelezhnikov <podtelez>
Project Member
Sun 20 Sep 2020 05:16:29 PM UTC, comment #35: 

comment #34:

> Piotr,
>
> > If anything, the specification might have a bug, not the renderer.
>
> I might agree with your explanation, but there is nothing about the right hand rule in the specifications, which only specify the non-zero winding number rule (no matter if +1 or -1) to turn a pixel ON and the boundary is ON. That is the law of the land.
>
> What you found is that GDI does not follow Rule 2 or Rule 2 is incomplete. Good luck with filing a bug with Microsoft.
>
>   
>
>


It is not reliable to use the specification anyway due to many quirks in the official proprietary Microsoft renderer. The right hand rule is one possible interpretation of the concept of winding, not explicitly stated in the specifications. Each contour is independent from another in changing the winding values of each pixel (half-pixels in an inside out square always point away from the square center regardless of other shapes, etc.), but the rendering may still depend on the point order due to dropout control. Please implement Six Pass Pixel Building.

Anonymous
Sun 20 Sep 2020 05:07:34 PM UTC, comment #34: 

Piotr,

> If anything, the specification might have a bug, not the renderer.


I might agree with your explanation, but there is nothing about the right hand rule in the specifications, which only specify the non-zero winding number rule (no matter if +1 or -1) to turn a pixel ON and the boundary is ON. That is the law of the land.

What you found is that GDI does not follow Rule 2 or Rule 2 is incomplete. Good luck with filing a bug with Microsoft.

  
Alexei Podtelezhnikov <podtelez>
Project Member
Sun 20 Sep 2020 04:09:20 PM UTC, comment #33: 

And by a right hand rule

comment #32:

> If anything, the specification might have a bug, not the renderer. It was likely the intent that a half pixel boundary doesn't turn the pixel on, but makes the winding value the higher value out of the two sides, and 0 is larger than -1 so the background is the value. The specification used bad wording but it's entirely unnecessary to take that literally.


And by a right hand rule this would imply that edges winding up would have half pixels of the right side, edges winding right would have half pixels of the down side, and so on. Which is exactly what Six Pass Pixel Building does.

Anonymous
Sun 20 Sep 2020 03:58:49 PM UTC, comment #32: 

If anything, the specification might have a bug, not the renderer. It was likely the intent that a half pixel boundary doesn't turn the pixel on, but makes the winding value the higher value out of the two sides, and 0 is larger than -1 so the background is the value. The specification used bad wording but it's entirely unnecessary to take that literally.

Anonymous
Sun 20 Sep 2020 03:55:11 PM UTC, comment #31: 

Please implement Six Pass Pixel Building to properly render half pixels of inside out shapes such as counters.

Anonymous
Sun 20 Sep 2020 03:47:19 PM UTC, comment #30: 

comment #29:

>
> comment #28:
> > $.PNG might demonstrate a bug in GDI. Notwithstanding that the top-right box has the wrong counter-clockwise orientation, the border pixels are inside according to Rule 2.
>
> Definitely not a GDI bug. Because the square is inside out, the inside is actually the background, so that is what the half pixels must render to. The right hand rule means when following the outline counter clockwise (inside out) the inside to the right of the direction is the background. It is the same shape as if this was, for instance, a hole inside a bigger square. FreeType gets all four edges incorrectly.


Also, most TrueType renderer specifications are undocumented. There's a reason everyone is trying to replicate Microsoft renderer and not the open specification itself, because nobody would implement exact precision calculations that no renderer uses in the first place, and most fully hinted fonts are made for the Microsoft renderer.

Anonymous
Sun 20 Sep 2020 03:37:12 PM UTC, comment #29: 

comment #28:

> $.PNG might demonstrate a bug in GDI. Notwithstanding that the top-right box has the wrong counter-clockwise orientation, the border pixels are inside according to Rule 2.


Definitely not a GDI bug. Because the square is inside out, the inside is actually the background, so that is what the half pixels must render to. The right hand rule means when following the outline counter clockwise (inside out) the inside to the right of the direction is the background. It is the same shape as if this was, for instance, a hole inside a bigger square. FreeType gets all four edges incorrectly.

Anonymous
Sun 20 Sep 2020 11:48:29 AM UTC, comment #28: 

$.PNG might demonstrate a bug in GDI. Notwithstanding that the top-right box has the wrong counter-clockwise orientation, the border pixels are inside according to Rule 2.

Alexei Podtelezhnikov <podtelez>
Project Member
Sun 20 Sep 2020 04:57:35 AM UTC, comment #27: 

comment #26:

> FreeType git HEAD now renders the box from comment #24 and boxy Riglos Mono font correctly.
>
> If a curve passes too close to a pixel center, different algorithms can produce produce different results due to rounding.  Please post real examples with real fonts so that I can investigate.


TrueTypefonttest2.ttf on glyph $ at 16ppem in the bilevel renderer

$.PNG — the proper rendering as produced by Microsoft renderer. Notice the inside out square is rounded inward. TD renderer 2.0 and up which uses Six Pass Pixel Building produces the exact same pixel pattern in this font configuration. FreeType 2.10.2 gets all four edges of the inside out square incorrect, as seen in $FT.PNG . SPBB$.PNG is attached to show how Six Pass Pixel Building correctly renders the dollar sign.

(file #49824,

Anonymous
Sat 19 Sep 2020 10:27:07 PM UTC, comment #26: 

FreeType git HEAD now renders the box from comment #24 and boxy Riglos Mono font correctly.

If a curve passes too close to a pixel center, different algorithms can produce produce different results due to rounding.  Please post real examples with real fonts so that I can investigate.

Alexei Podtelezhnikov <podtelez>
Project Member
Sat 19 Sep 2020 05:48:12 PM UTC, comment #25: 

comment #24:

> This is how six pass Pixel Building looks like, and TD renderer uses it starting with version 2.0 . TD renderer 1.0 was glitched due to not implementing the last two passes, and FreeType is glitched because none of the passes are implemented properly.
>
> SPPB.PNG
>
>


And this is its implementation:

On a pixel buffer (extending horizontally to bounding box and vertically to bounding box or font height boundaries) perform the pass 3, adding 1 to each pixel encountered. Then pass 4, subtracting 1 from each pixel encountered.
On a second pixel buffer similarly do pass 5 and pass 6.
Merge the buffers by taking the max value for each pixel.
Perform pass 1 and pass 2 similarly but in the other dimension. Now each inside pixel is of value 2, or 1. Each value greater than 0 or less than -1 is a filled pixel.

Anonymous
Sat 19 Sep 2020 05:10:15 PM UTC, comment #24: 

This is how six pass Pixel Building looks like, and TD renderer uses it starting with version 2.0 . TD renderer 1.0 was glitched due to not implementing the last two passes, and FreeType is glitched because none of the passes are implemented properly.

SPPB.PNG


Anonymous
Sat 19 Sep 2020 04:53:15 PM UTC, comment #23: 

Note the Quadratic Formula:

The main way to turn quadratic outlines into pixel borders. This must be done twice horizontally and once vertically for correct rendering, for proper handling of half pixel corners later. This step is followed by Pixel Building inside the borders, done in one pass each for the top and bottom edges, and two passes each for left and right edges. The possibility of missing extrema is ignored.

First, we have to turn the Quadratic Bezier into a Quadratic Polynomial: for each dimension, given the points a, b, c, the quadratic function where f(0)=a and f(1)=c (curve goes from 0 to 1) is (a)x⁰+(2*(b-a))x¹+((c+a)-(2*b))x².

We have the quadratic polynomial, (q)x⁰+(w)x¹+(e)x². In both horizontal and vertical dimensions, where the curve goes from 0 to 1.

We apply this rule: For each half pixel position (let's say, j) along a dimension we place an edge. First we apply the Quadratic Formula to determine at what location on the curve the coordinate is located.
It is located at
double r = j-q; double t = w/(-2.0*e); double y; if(1.0/t == 0.0) y = r/w; else if(t<0.5) y = t+sqrt((t*t)+(r/e)); else y = t-sqrt((t*t)+(r/e)); return y;
With the location now known, it is possible to determine where the edge would be. On the other dimension, we simply do (q)x⁰+(w)x¹+(e)x² with the obtained location. It must then be rounded to nearest integer. For half-rounding note that because pixels on TOP of the outline are inside, half-edges on the top and right are rounded up, while half-edges on the bottom and left are rounded down.
The Quadratic Formula is absolutely necessary to rasterize quadratic outlines. It can be figured out with a lot of mathematical thinking, however it is very common to make mistakes in implementation of it.

This is an important rendering note, and it seems that you are not always rounding half-edges on the top and bottom correctly. I have also seen that if the outline is inside out all four edges are incorrect, they should actually round inward when inside out. The only way to fix this is to do one pass each for the top and bottom edges, and two passes each for left and right edges.

Anonymous
Sun 13 Sep 2020 06:12:09 PM UTC, comment #22: 

A fix is committed.

Alexei Podtelezhnikov <podtelez>
Project Member
Fri 11 Sep 2020 08:59:44 PM UTC, comment #21: 

It is hard to handle horizontal lines in vertical sweep because they have ambiguous intersection profile when aligned to pixel centers. To demonstrate the bug

ftgrid -k$'hd\xF5' -f14 21 ../tahoma.ttf

To fix this we need the second horizontal pass. Specifically, we need to rework Horizontal_Sweep_Span. See attached patch.

The question remains if we can revise the vertical sweep and drop Horizontal_Sweep_Span altogether.

(file #49789)

Alexei Podtelezhnikov <podtelez>
Project Member
Mon 24 Aug 2020 11:01:28 AM UTC, comment #20: 

In Half pixel glitching — standard rendering and subpixel rendering.PNG it is demonstrated that when the render modes are properly simulated (because in both render modes vertical anti-aliasing can be disabled by the gasp table) FreeType rendering results in Half pixel glitching in both render modes.

The subpixel render is based on the actual v38 outlines but scaled six times horizontally and rasterized with FreeType bilevel rasterizer, using this method:

First, the v38 engine is enabled, then

FT_Load_Glyph(face, glyph, FT_LOAD_NO_BITMAP|FT_LOAD_TARGET_MONO|FT_LOAD_NO_AUTOHINT);
for(int_fast64_t i=0; i<face->glyph->outline.n_points; i++){
face->glyph->outline.points[i].x *= 6;
face->glyph->outline.points[i].y *= 1;
}
FT_Render_Glyph(face->glyph, FT_RENDER_MODE_MONO);

Then the resulting image is scaled down six times with a gamma correct box filter and the red channel shifted 2 pixels right and blue channel shifted 2 pixels left.


- <_194785>
Thu 13 Aug 2020 07:48:00 AM UTC, comment #19: 

comment #18:

>
> comment #17:
> > each glitched bilevel pixel corresponds to an incorrectly sampled fraction of a pixel.
>
> Correct, but
>
> (1) Instead of (over)sampling, we actually integrate the coverage. So the impact of your observations is limited to bilevel rendering.
> (2) Even if we did oversampling, the incorrect fraction is hardly noticeable to a naked eye on modern HD monitors.
>
> So fixing these bugs has very very very limited ROI. I invite you to fix these rounding discrepancies if they bother you so much.


Have you researched the font? In this bug report, Riglos Mono 1.1 at 24ppem is used to demonstrate the issue, and investigating this font reveals that as seen in the gasp table, the font is not intended to be anti-aliased.

"The world has moved on to anti-aliasing since. " You are going circular here. It is because of the mass explosion in the amount of FreeType renderers built in software. No Microsoft renderer would anti-alias Riglos Mono vertically, because it is not enabled in the font.

"I invite you to fix these rounding discrepancies if they bother you so much. " What do you expect? I did not write the code, so I have no idea what is happening in the renderer. It clearly would have been reasonable to assign this to the creators of the FreeType bilevel renderer, because they are the ones who made it. It goes against the fundamental standards of TrueType rendering on many simple outlines because of Half pixel glitching, so I don't see an excuse for this.

- <_194785>
Wed 12 Aug 2020 01:56:30 PM UTC, comment #18: 

comment #17:

> each glitched bilevel pixel corresponds to an incorrectly sampled fraction of a pixel.


Correct, but

(1) Instead of (over)sampling, we actually integrate the coverage. So the impact of your observations is limited to bilevel rendering.
(2) Even if we did oversampling, the incorrect fraction is hardly noticeable to a naked eye on modern HD monitors.

So fixing these bugs has very very very limited ROI. I invite you to fix these rounding discrepancies if they bother you so much.

Alexei Podtelezhnikov <podtelez>
Project Member
Wed 12 Aug 2020 01:00:46 PM UTC, comment #17: 

It is also important to note that every Microsoft renderer as far as I know is based on the bilevel renderer. So simulating any Microsoft renderer with the FreeType renderer, the bilevel glitches will pop up in all of them for some inputs, where each glitched bilevel pixel corresponds to an incorrectly sampled fraction of a pixel. So, it really affects both bilevel rendering and grayscale rendering, when using oversampled anti-aliasing. Any bilevel glitching is therefore extremely important for the purposes of software preservation. The anti-aliasing, which a font doesn't even have to enable, should not distract from the glitching in the bilevel renderer, which is the very main core of rendering. The bilevel renderer is an inseparable part of TrueType rendering.

- <_194785>
Wed 12 Aug 2020 12:27:29 PM UTC, comment #16: 

I just want to say thank you Piotr for reporting this bug: reporting bugs take time, and you did an amazing job of describing this one in detail, so that perhaps it can be fixed in the future. This is beneficial to the whole open source community. Thank you.

I am a little confused why some of your explanations were dismissed as "trolling", but I hope you will still continue to report bugs in the future whenever you find them, it really helps.

I agree that pixel-perfect accuracy, when anti-aliasing is disabled, is a desirable goal for any font rendering library. Of course, most modern fonts and operating systems do rely on anti-aliasing, so I understand why this can be seen as low priority. But still, if anti-aliasing is explicitly disabled by a font, then it would be best if FreeType didn't have the glitches you describe.

Boris Dalstein <dalboris>
Tue 19 May 2020 06:30:42 PM UTC, comment #15: 

comment #14:

> I have only tried to explain to you why your bug is low priority, The bug priority is on-topic, of course.
>

This bug does not complain about its own priority, it complains about something unrelated to the priority itself. Therefore it is off-topic.

> Would you kindly stop trolling until you have more information or, better yet, a patch?

What are you talking about? I do not know any of FreeType's code because it is completely immense and I did not write a single character of it, therefore there's no way I'm supposed to know what any piece of FreeType's code specifically does.

- <_194785>
Tue 19 May 2020 06:10:50 PM UTC, comment #14: 

I have only tried to explain to you why your bug is low priority, The bug priority is on-topic, of course.

Would you kindly stop trolling until you have more information or, better yet, a patch?

Alexei Podtelezhnikov <podtelez>
Project Member
Tue 19 May 2020 05:54:41 PM UTC, comment #13: 

comment #12:

> > Riglos Mono 1.1 does not allow anti-aliasing in the gasp table.
>
> So what? When are you going to grow up and finally realize that your list of priorities in life is different from mine?
>
> Yes there is a bug. Ok? Until you come and fix my kid's bicycle that is still my top priority.
>
> Stop trolling!


What is this off-topic post? The FreeType community is supposed to be investigating everything in this bug, not posting off-topic.

- <_194785>
Tue 19 May 2020 05:43:02 PM UTC, comment #12: 

> Riglos Mono 1.1 does not allow anti-aliasing in the gasp table.


So what? When are you going to grow up and finally realize that your list of priorities in life is different from mine?

Yes there is a bug. Ok? Until you come and fix my kid's bicycle that is still my top priority.

Stop trolling!

Alexei Podtelezhnikov <podtelez>
Project Member
Tue 19 May 2020 05:17:20 PM UTC, comment #11: 

comment #10:

> >  A rendering glitch is a rendering glitch, no matter what the renderer mode is.
>
> You are so wrong here. The algorithms are so different. In this particular bug, half-points are obviously half-toned with anti-aliasing so to speak.

Riglos Mono 1.1 does not allow anti-aliasing in the gasp table. And this specific bug is for the bilevel rasterizer. But the rasterizer by itself doesn't make it a glitch or not, it's the entire setup that shows the rendering glitch. Changing the rasterizer changes the entire glitch and makes it invalid, like changing 2=2 to 3=2. Anti-aliasing is completely off-topic for this glitch.

>
> The old b/w rasterizer just exaggerates small rounding errors and half pixels, which you just won't see in the anti-aliased world. So it is a good tool in a sense. 

This is like comparing apples to oranges.

> The world is evolving, there are alternatives to Microsoft now. Apple and Adobe, for example, have even stopped hinting fonts, because they concluded that (subpixel) glyph spacing is much more important. Ultimately, what matters is user's experience (which is very subjective too), not some idealistic bit-identity with GDI.
>

You can't expect to make the bug invalid by changing it. The Microsoft TrueType renderer is considered the reference bilevel renderer because many fonts are designed to run on the Microsoft renderer. Please stop going off-topic because you could be wasting time.

- <_194785>
Tue 19 May 2020 04:13:34 PM UTC, comment #10: 

>  A rendering glitch is a rendering glitch, no matter what the renderer mode is.


You are so wrong here. The algorithms are so different. In this particular bug, half-points are obviously half-toned with anti-aliasing so to speak.

The old b/w rasterizer just exaggerates small rounding errors and half pixels, which you just won't see in the anti-aliased world. So it is a good tool in a sense. 

The world is evolving, there are alternatives to Microsoft now. Apple and Adobe, for example, have even stopped hinting fonts, because they concluded that (subpixel) glyph spacing is much more important. Ultimately, what matters is user's experience (which is very subjective too), not some idealistic bit-identity with GDI.

Alexei Podtelezhnikov <podtelez>
Project Member
Tue 19 May 2020 03:50:33 PM UTC, comment #9: 

comment #8:

> I trust that you identified the bug correctly. I hope you realize that this these renderers were cool more than 20 years ago. The world has moved on to anti-aliasing since.

That doesn't make any sense. Riglos Mono 1.1 disables anti-aliasing in all sizes as seen in the gasp table. A rendering glitch is a rendering glitch, no matter what the renderer mode is, no matter what the renderer mode is supposed to be, no matter what rendering mode is trending.

> We lived with the bug for 20 years and we can wait a little longer to fix it.

Are you being sarcastic?

> Even you have a chance to verify it in FreeType 2.10.2 and even fix it for us. We have time.


Here it is: https://i.imgur.com/TPibpGG.png
FreeType 2.9.1 has Half pixel glitching both horizontally and vertically. FreeType 2.10.2 appears to have no Half pixel glitching horizontally, but it still has Half pixel glitching vertically. This seems to be based on direction in a bizarre way.

- <_194785>
Sun 17 May 2020 06:35:38 PM UTC, comment #8: 

I trust that you identified the bug correctly. I hope you realize that this these renderers were cool more than 20 years ago. The world has moved on to anti-aliasing since.

We lived with the bug for 20 years and we can wait a little longer to fix it. Even you have a chance to verify it in FreeType 2.10.2 and even fix it for us. We have time.

Alexei Podtelezhnikov <podtelez>
Project Member
Sun 17 May 2020 06:06:34 PM UTC, comment #7: 

This is the current comparison. https://i.imgur.com/xFhqMRY.png . TD renderer as of version 2.0 is now pixel-for-pixel identical to GDI rendering in this particular font configuration, but is off-topic for FreeType development. The Half pixel glitching in FreeType is yet to be officially verified.

- <_194785>
Sat 16 May 2020 07:28:08 PM UTC, comment #6: 

comment #5:

> I was talking about SCANTYPE.
>


Ok and every possible case includes rules 1 and 2, and FreeType is not working properly. What is causing this bizarre issue? I am working on fixing unrelated problems in my TD renderer rasterizer to hopefully make it a more accurate rasterizer, already having fixed my unrelated half pixel bug (shown in the picture) in development.

- <_194785>
Sat 16 May 2020 01:18:10 PM UTC, comment #5: 

I was talking about SCANTYPE.

Alexei Podtelezhnikov <podtelez>
Project Member
Fri 15 May 2020 07:31:42 PM UTC, comment #4: 

comment #1:

> Piotr,
>
> Also make sure that you detrmine the scan converter mode for the fonts that you study.


It's evident:

"Riglos Mono 1.1 at 24ppem"

Doing some research into this font shows that the gasp table says it must be rendered with no anti-aliasing. "Microsoft Arial Regular at 17ppem" or "Microsoft Tahoma Bold at 9ppem" would imply this as well.

- <_194785>
Fri 15 May 2020 07:25:18 PM UTC, comment #3: 

comment #2:

> Microsoft and Apple set rules quite similarly. FreeType tries to follow these rules. 


"Rule 2
    If a contour falls exactly on a pixel’s center, that pixel is turned on."
However, it is observed that some lines of pixels get incorrectly left off.

- <_194785>
Fri 15 May 2020 06:57:31 PM UTC, comment #2: 

Microsoft and Apple set rules quite similarly. FreeType tries to follow these rules. 

Alexei Podtelezhnikov <podtelez>
Project Member
Fri 15 May 2020 06:30:32 PM UTC, comment #1: 

Piotr,

I appreciate your effort and you seem to understand how the b/w rasterizer is supposed to work. You probably even know the rules as they are described here. Therfore, let's raise the level of your reporting. You have to identify the exact rule that is broken. Also make sure that you detrmine the scan converter mode for the fonts that you study.

The font life was tough back in the 90s. Most people moved on.

Alexei Podtelezhnikov <podtelez>
Project Member
Fri 15 May 2020 01:29:11 PM UTC, original submission:  

I found a glitch named Half pixel glitching. What happens is that in some half pixel structures, FreeType marks pixels blank incorrectly.

The font Riglos Mono 1.1 at 24ppem can demonstrate this problem: https://i.imgur.com/KRt5T38.png

Note how in some parts of glyphs FreeType ceases to work properly and marks the halfway pixels on some stems as blank when points on an outline should be enabled (and conversely for counters).

- <_194785>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #49824:  TrueTypefonttest2.ttf added by None (8KiB - application/octet-stream)
file #49825:  $.PNG added by None (174B - image/png)
file #49826:  $FT.PNG added by None (174B - image/png)
file #49827:  SPBB$.PNG added by None (16KiB - image/png)
file #49820:  SPPB.PNG added by None (7KiB - image/png)
file #49789:  half_pixel_1.diff added by podtelez (2KiB - 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 dalboris (Posted a comment)
  • -email is unavailable- added by podtelez (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.

    Only logged-in users can vote.

     

     

     

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-11-11 None Attached File- => Added Half@pixel@glitching@—@counterclockwise@rectangles@in@deliberate@incompatibility.PNG, #50252
    2020-09-20 None Attached File- => Added TrueTypefonttest2.ttf, #49824
        Attached File- => Added $.PNG, #49825
        Attached File- => Added $FT.PNG, #49826
        Attached File- => Added SPBB$.PNG, #49827
    2020-09-19 None Attached File- => Added SPPB.PNG, #49820
    2020-09-13 podtelez StatusNone => Ready For Test
    2020-09-11 podtelez Attached File- => Added half_pixel_1.diff, #49789
        Planned ReleaseNone => 2.10.3
    2020-08-24 _194785 Attached File- => Added Half@pixel@glitching@—@standard@rendering@and@subpixel@rendering.PNG, #49701
    2020-05-19 podtelez Severity3 - Normal => 1 - Wish

    Back to the top


    Powered by Savane 3.9