On Wed, Dec 19, 2018 at 10:35 AM Behdad Esfahbod wrote:
>
> On Wed, Dec 19, 2018 at 9:08 AM Alexei Podtelezhnikov
> wrote:
>>
>> On Wed, Dec 19, 2018 at 5:43 AM Alexei Podtelezhnikov
>> wrote:
>> > > Alexei, I think we miscommunicate.
>> >
>> > I struggle to get your attention to
On Wed, Dec 19, 2018 at 9:08 AM Alexei Podtelezhnikov
wrote:
> On Wed, Dec 19, 2018 at 5:43 AM Alexei Podtelezhnikov
> wrote:
> > > Alexei, I think we miscommunicate.
> >
> > I struggle to get your attention to FT_Glyph_To_Bitmap.
>
> I just discovered that, while ignoring the FT_Glyph
On Wed, Dec 19, 2018 at 5:43 AM Alexei Podtelezhnikov
wrote:
> > Alexei, I think we miscommunicate.
>
> I struggle to get your attention to FT_Glyph_To_Bitmap.
I just discovered that, while ignoring the FT_Glyph abstraction in the
current implementation, we also disregard FreeType caching
On Tue, Dec 18, 2018 at 5:35 AM Werner LEMBERG wrote:
>
> >> FreeType is about to make a major leap into color rendering.
> >
> > Is it? Color rendering was the news before variable-fonts were
> > news. So 2013. The world has moved on.
>
> You completely misunderstood. Alexei talks about
On Wed, Dec 19, 2018 at 5:43 AM Alexei Podtelezhnikov
wrote:
> FT_Render_Glyph used to be democratic. The renderers were chosen based
> on the match between the glyph format and the rendering mode. The only
> way to keep it this way is either FT_RENDER_MODE_BGRA or
> FT_GLYPH_FORMAT_LAYERED.
Hi Werner,
> FT_LOAD_COLOR will *never* set
> FT_LOAD_RENDER. How do you come to this impression? We are only
> talking about the effect of FT_LOAD_COLOR on the rendering of
> color-layered glyphs.
Wonderful!
> Alexei, I think we miscommunicate.
I struggle to get your attention to
>> FT_LOAD_COLOR should trigger a standard case with some default
>> blending; for finer color and blending control separate functions
>> should be provided to allow direct layer access.
>
> Which [of] is these flags is spurious?
> FT_LOAD_COLOR | FT_LOAD_RENDER | FT_LOAD_TARGET_BGRA
>
> I am
> > FT_LOAD_COLOR used to be a loading flag only.
>
> This depends on what you exactly mean with `loading' and
> `rendering'...
Naturally, the rendering is FT_Render_Glyph, which takes render_mode.
Because FT_Glyph's are rendered with dummy FT_Face, we cannot and must
not use FT_LOAD_COLOR or
>> Let's see whether someone is interested in this. What about making
>>
>> Add SVG support
>>
>> a GSoC project? :-)
>
> Ooohhh that's an extremely interesting and tempting thing; I wish I
> could participate again (or had more time in general) :D
The former is possible AFAIK, the latter
> Let's see whether someone is interested in this. What about making
>
> Add SVG support
>
> a GSoC project? :-)
Ooohhh that's an extremely interesting and tempting thing; I wish I could
participate again (or had more time in general) :D
___
>> FreeType is about to make a major leap into color rendering.
>
> Is it? Color rendering was the news before variable-fonts were
> news. So 2013. The world has moved on.
You completely misunderstood. Alexei talks about FreeType, not about
the latest font news.
>> It is possible to make
>>> > As long as adding FT_LOAD_COLOR will get COLR/CPAL glyphs
>>> > rendered into the bitmap, cairo/Chrome will work fine and I have
>>> > no problem with that.
>>
>> FT_LOAD_COLOR has been FreeType public API since 2013.
>
> FT_LOAD_COLOR used to be a loading flag only.
This depends on what
> All I'm asking is, if FT_LOAD_COLOR is passed to FT_Load_Glyph() then color
> bitmap be rendered. How it trickles down the abstractions and machinery
> into render, you can change.
You object to explicit spelling FT_LOAD_COLOR | FT_LOAD_TARGET_BGRA |
FT_LOAD_RENDER. Otherwise, you
On Sat, Dec 15, 2018 at 11:10 PM Alexei Podtelezhnikov
wrote:
>
> FreeType is about to make a major leap into color rendering.
Is it? Color rendering was the news before variable-fonts were news. So
2013. The world has moved on.
> It is
> possible to make it right while keeping rendering
On Sat, Dec 15, 2018 at 2:55 PM Behdad Esfahbod wrote:
>> It is wrong to use
>> FT_LOAD_COLOR in FT_Render_Glyph. There is a way to properly pass all
>> necessary information.to that function.
>
> I understand your desire to encode all info into FT_Outline; but given how
> much glyphslot is
On Fri, Dec 14, 2018 at 8:25 AM Alexei Podtelezhnikov
wrote:
> >> > As long as adding FT_LOAD_COLOR will get COLR/CPAL glyphs rendered
> into the bitmap, cairo/Chrome will work fine and I have no problem with
> that.
> >
> >> You started to use unreleased features.
> >
> > FT_LOAD_COLOR has been
>> > As long as adding FT_LOAD_COLOR will get COLR/CPAL glyphs rendered into
>> > the bitmap, cairo/Chrome will work fine and I have no problem with that.
>
>> You started to use unreleased features.
>
> FT_LOAD_COLOR has been FreeType public API since 2013.
FT_LOAD_COLOR used to be a loading
On Thu, Dec 13, 2018 at 12:28 PM Alexei Podtelezhnikov
wrote:
> > As long as adding FT_LOAD_COLOR will get COLR/CPAL glyphs rendered into
> the bitmap, cairo/Chrome will work fine and I have no problem with that.
>
> This is just unfair. FreeType is not paid by or owned by Google.
Did I imply
>> ??? What do we break? COLR/CPAL support will be *new* in 2.10.0,
>> it wasn't present in the 2.9.x series. We don't plan to drop the
>> FT_PIXEL_MODE_RGBA mode that you've added for CBDT/CBLC/sbix
>> support.
>
> As long as adding FT_LOAD_COLOR will get COLR/CPAL glyphs rendered
> into
> As long as adding FT_LOAD_COLOR will get COLR/CPAL glyphs rendered into the
> bitmap, cairo/Chrome will work fine and I have no problem with that.
This is just unfair. FreeType is not paid by or owned by Google. You
started to use unreleased features. Also Google did not contribute
that code.
On Thu, Dec 13, 2018 at 11:55 AM Werner LEMBERG wrote:
>
> >> > As long as you don't break cairo and Chrome, I don't care what
> >> > you do.
> >
> > [...] and annoyed that you change things without caring about
> > breaking things.
>
> ??? What do we break? COLR/CPAL support will be *new* in
>> > As long as you don't break cairo and Chrome, I don't care what
>> > you do.
>
> [...] and annoyed that you change things without caring about
> breaking things.
??? What do we break? COLR/CPAL support will be *new* in 2.10.0, it
wasn't present in the 2.9.x series. We don't plan to drop
On Thu, Dec 13, 2018 at 10:27 AM Alexei Podtelezhnikov
wrote:
> On Thu, Dec 13, 2018 at 10:23 AM Behdad Esfahbod
> wrote:
> >
> > As long as you don't break cairo and Chrome, I don't care what you do.
> >
>
> That is not how it works. Please help up to make FreeType better.
>
> I hate to say
On Thu, Dec 13, 2018 at 10:23 AM Behdad Esfahbod wrote:
>
> As long as you don't break cairo and Chrome, I don't care what you do.
>
That is not how it works. Please help up to make FreeType better.
I hate to say it, but somebody should, you have been quite obnoxious
recently. You one sentence
As long as you don't break cairo and Chrome, I don't care what you do.
On Thu, Dec 13, 2018 at 10:04 AM Alexei Podtelezhnikov
wrote:
> >> Once the TrueType loader learns to combine
> >> all layers into a single outline and fill color information, it is
> >> good to go. Just load and render
>> Once the TrueType loader learns to combine
>> all layers into a single outline and fill color information, it is
>> good to go. Just load and render those with FT_RENDER_MODE_BGRA.
>
> What was wrong with the existing code / model?
>
C'mon guys! Admit that the current implementation has tons
>> Just load and render those with FT_RENDER_MODE_BGRA.
>
> What was wrong with the existing code / model?
The current implementation relies on FT_LOAD_COLOR and is contrary to
FreeType design. Even ft2demos do not support it, besides ftview,
which is forced to copy the the entire rendering code.
On Tue, Dec 11, 2018 at 11:49 PM Alexei Podtelezhnikov
wrote:
> Hi all,
>
> I have just pushed out a new branch called color. This is a framework
> and renderer for color glyphs, which Werner and I discussed offline.
> The basic idea is to supplement outlines with color information for
> each
28 matches
Mail list logo
