[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ft-devel] FT_Bitmap_Convert, and FreeType's bitmap format vs Cairo's
From: |
Hin-Tak Leung |
Subject: |
[ft-devel] FT_Bitmap_Convert, and FreeType's bitmap format vs Cairo's |
Date: |
Tue, 25 Apr 2017 02:35:59 +0000 (UTC) |
Hi,
FT_Bitmap_Convert's documentation is somewhat lacking in description of what it
would do to
FT_PIXEL_MODE_LCD,
FT_PIXEL_MODE_LCD_V
FT_PIXEL_MODE_BGRA
The behavior for FT_PIXEL_MODE_LCD and FT_PIXEL_MODE_LCD_V seems to be
a bit unexpected. It copies the pixel buffer as is, but changes the pixel mode
from
FT_PIXEL_MODE_LCD/FT_PIXEL_MODE_LCD_V to FT_PIXEL_MODE_GRAY .
afaic, FT_PIXEL_MODE_BGRA is flattened and converted to grays, which is sort of
reasonable behavior.
I was somewhat expecting these three to throw Invalid Arg error, actually.
The reason why I was looking at FT_Bitmap_Convert is that I was looking for
converting
FreeType's bitmap format vs Cairo's . I found only the 8-bit gray format works.
The 1-bit format
has the wrong bit order on little-endian platforms - freetype's is always MSB
first, while cairo's is host-order
( https://github.com/ldo/python_freetype/issues/1
https://github.com/ldo/python_freetype_examples/issues/1 )
Cairo does not have a 24-bit format - its RGB24 format is 32-bit with the
highest 8-bit not used.
I have worked around the 1-bit problem with libtiff's TIFFReverseBits (any
bitswapping routine from a common
library would do - I was trying to stay within python/freetype-py/pycairo
without writing new C code)
- and I was hoping to overload FT_Bitmap_Convert()
if it currently rejects FT_PIXEL_MODE_BGRA to convert to cairo's ARGB32 , but
that's dead-end.
Anyway, anybody has any bright idea about converting between freetype's the 3
24-bit/32-bit bitmap buffers
to cairo's RGB24 or ARGB32, without writing custom C code? And pwehaps also
solving the 1-bit issue better?
I am hoping to add a
FT_Bitmap_Convert_More(..., FT_PIXEL_MODE)
and perhaps adds a few more FT_PIXEL_MODE_* enums?
Also I am wondering about a little drawing issue I have - I want to scale a
freetype bitmap up and draw a larger version of it (useful for illustrations
for rasterization issues...) but it seems that cairo always anti-alias the
edges at the original resolution, and I haven't figured out how to turn it off
yet.
Let's say, I have rendered a glyph to a 24x24 grid in FreeType, and want to
draw that in cairo to 480 x 480 . I'd like cairo to render at the destination
resolution - i.e. do whatever at the 1-pixel boundary in 480x480, but it seems
that it is doing it in the original grid, which blows up to be extra blurry at
~20 pixels wide in 480x480. Here is how it looks (the corner S is original
resolution drawn as is):
http://htl10.users.sourceforge.net/tmp/S.png
This is from a word-in-progress rewrite of freetype-py's
glyph-alpha/glyph-monochrome examples which uses numpy and matplotlib, to using
pycairo for drawing.
Hin-Tak
- [ft-devel] FT_Bitmap_Convert, and FreeType's bitmap format vs Cairo's,
Hin-Tak Leung <=