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

Submitted by:  Toshio Nakamura <tnakamura>
Submitted on:  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
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       No canned response available

 

( 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>
Project 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>
Project 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>
Project 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>
Project Administrator
Fri 21 Sep 2018 02:45:53 AM UTC, comment #8: 

ft_glyphslot_preset_bitmap should be fixed.

Alexei Podtelezhnikov <podtelez>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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.)

Attach Files:
   
   
Comment:
   

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.

    Only logged-in users can vote.

     

     

     

     

    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.9