bugThe FreeType Project - Bugs: bug #54589, Some Vertical Line characters of...

 
 

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

bug #54589: Some Vertical Line characters of Japanese fonts disappeared without anti-alias

Submitter:  Toshio Nakamura <tnakamura>
Submitted:  Wed 29 Aug 2018 10:12:15 AM UTC
   
 
Severity:  3 - Normal Item Group:  Incorrect behaviour
Status:  Fixed Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  2.10.0

Jump to the original submission

Tue 19 May 2020 06:06:54 PM UTC, comment #14: 

Werner,

You fixed this bug for vertical stems only, but it remains in horizontal stems. I wonder if the fix is easy to apply there as well. Then we can possibly close bug 58373.

Thank you.

Alexei Podtelezhnikov <podtelez>
Group Member
Thu 15 Nov 2018 08:05:41 PM UTC, comment #13: 

You seem to have fixed Vertical_Sweep_Span, but horizontal lines exactly aligned with pixel centers are still dropping out.

To reproduce this, you need to set ppem to 25, so that the default stroker radius results in 1 pixel stokes.

% ftview 25 ariblk.ttf

then go to stroked monochrome display, '3' and 'k', and observe horizontal drop-outs in +, E, F, 5... It is extremely ugly in comparison to size 24. I no longer see vertical dropout after your fix.

This is duplicate of bug #51339 also.

Alexei Podtelezhnikov <podtelez>
Group Member
Tue 25 Sep 2018 06:03:52 AM UTC, comment #12: 

I see. Thank you for your reply.

Toshio Nakamura <tnakamura>
Tue 25 Sep 2018 05:38:28 AM UTC, comment #11: 

I can only repeat: for outline fonts only FreeType's TrueType font driver has proper monochrome hinting support (provided the font contains bytecode for B/W hinting).  `NotoSerifCJKjp-Regular.otf', as the extention `.otf' already indicates, is not a TTF!  It's a CFF and thus can't be rendered well as B/W at small sizes.

Werner LEMBERG <wl>
Group administrator
Mon 24 Sep 2018 02:21:44 PM UTC, comment #10: 

Thank you so much for fixing our problem.
I verified OpenSans-Light.ttf, mingliub.ttc, and VL-Gothic-Regular.ttf worked very well.

On the other hand, NotoSerifCJKjp-Regular.otf still doesn't show some characters.
8points: \u2506\u250A
10points: \u250A
12points: \u250A
Can I open another report?

Toshio Nakamura <tnakamura>
Fri 21 Sep 2018 09:11:23 AM UTC, comment #9: 

And the B/W rasterizer is now fixed, too.

Please test!

Werner LEMBERG <wl>
Group administrator
Fri 21 Sep 2018 02:45:53 AM UTC, comment #8: 

ft_glyphslot_preset_bitmap should be fixed.

Alexei Podtelezhnikov <podtelez>
Group Member
Wed 19 Sep 2018 10:25:38 AM UTC, comment #7: 

I've now taken a closer look – thanks for being pertinent :-)

The issue unveils actually two bugs in FreeType: The generic function `ft_glyphslot_preset_bitmap' returns an incorrect bounding box sometimes, and `Vertical_Sweep_Span' (not the dropout handling code, BTW) doesn't render all necessary pixels in a scanline if stem edges align with pixel centers.

Werner LEMBERG <wl>
Group administrator
Wed 19 Sep 2018 03:33:29 AM UTC, comment #6: 

Thank you for your reply. I understood that.
Could you reopen this report, please?

Toshio Nakamura <tnakamura>
Tue 18 Sep 2018 01:24:14 PM UTC, comment #5: 

I am aware of the issue in the dropout control code. I cannot commit to a time line to fix it however.

Alexei Podtelezhnikov <podtelez>
Group Member
Tue 18 Sep 2018 12:59:41 PM UTC, comment #4: 

I found some bigger fonts also had this problem.
Additionally, this problem is not only with Japanese fonts, but also with English or Taiwanese fonts.
Could you reevaluate this, please?

OpenSans-Light.ttf
https://github.com/google/fonts/tree/master/apache/opensans
size:22 \u007c\u00a6
    \u007c VERTICAL LINE
    \u00a6 BROKEN BAR

mingliub.ttc (Win7 Taiwanese)
size:16 \u00a6

mingliu.ttc (Win7 Taiwanese)
No problem (It seems this problem depends on glyph data.)

Toshio Nakamura <tnakamura>
Sun 16 Sep 2018 05:33:18 AM UTC, comment #3: 

I've just added the following to `freetype.h':



Note that for outline fonts only the TrueType font driver has proper monochrome hinting support, provided the TTFs contain hints for B/W rendering (which most fonts no longer provide).  If these conditions are not met it is very likely that you get ugly results at smaller sizes.



Closing as `won't fix'.  If you need B/W rendering of CJK fonts at small sizes you should use a TTF that contains B/W hints (for example, the famous `mingli.ttf' (from 1994), or a font that contains embedded bitmaps for the requested ppem values.

Werner LEMBERG <wl>
Group administrator
Thu 13 Sep 2018 10:44:09 AM UTC, comment #2: 

This problem was found by Java application. Its AWT components are working without anti-aliasing. And, there are a lot of legacy applications on active, I think.
By the way, I reported this problem to OpenJDK as well.
https://bugs.openjdk.java.net/browse/JDK-8210707

Toshio Nakamura <tnakamura>
Thu 30 Aug 2018 03:46:31 PM UTC, comment #1: 

This is a flaw in dropout control of monochrome rasterizer when the stem edges precisely align with pixel centers. Perhaps there is a strict instead of non-strict inequality bug somewhere. We lack motivation to track it down because the monochrome rasterizer is not very popular these days.

This is a likely duplicate of bug 51339.

Alexei Podtelezhnikov <podtelez>
Group Member
Wed 29 Aug 2018 10:12:15 AM UTC, original submission:  

I could recreate the problem with demo program.
$ ./ftview -l 0 -m 'a¦丨︱|¦│┆┊b' -e unic 12 VL-Gothic-Regular.ttf

The test string in Unicode is
"\u00A6\u4e28\uFE31\uFF5C\uFFE4\u2502\u2506\u250A"

The following characters are not displayed.
NotoSerif:
  8points: \u2506\u250A
  10points: \u250A
  12points: \u250A

VL Gothic:
  12points: \u4e28
  22points: \u2502\u2506\u250A

The problem didn't occur with anti-alias on.
Embedded bitmap is not affected.

VL Gothic
http://vlgothic.dicey.org/download.html
Noto Serif CJK JP
https://www.google.com/get/noto/

Toshio Nakamura <tnakamura>

 

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

Attached Files
file #44894:  NotoImage.png added by tnakamura (86KiB - image/png)
file #44895:  VLGothicImage.png added by tnakamura (89KiB - image/png)

 

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 podtelez (Posted a comment)
  • -email is unavailable- added by tnakamura (Submitted the item)
  • -email is unavailable- added by tnakamura
  •  

    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 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-09-21 wl StatusConfirmed Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 2.10.0
    2018-09-19 wl StatusWont Fix Confirmed
        Open/ClosedClosed Open
    2018-09-16 wl StatusNone Wont Fix
        Assigned toNone wl
        Open/ClosedOpen Closed
    2018-08-29 tnakamura Attached File- Added NotoImage.png, #44894
        Attached File- Added VLGothicImage.png, #44895
        Carbon-Copy- Added tnakamura

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code