> The next thing I'm doing for the adjustment database is making
> combining characters work. Currently, only precomposed characters
> will be adjusted. If my understanding is correct, this would mean
> finding any lookups that map a character + combining character onto
> a glyph, then apply
> Perhaps it is easier just to show you what I have - this is already
> functional and I can even switch COLRv1 palettes in ftgrid
> (screenshots the usual place).
…and where is this ‘usual place’? I can’t see screenshots anywhere.
Regards,
Brad
Thank you Hin-Tak.
I have checked the makefile of demos and used libs and the includes as there.
(it was overriding the ccraw to cc)
about percentages, i runned the bench with -c 200 to have instant results for
development process. here in the benchmark file attached, it made more
acceptable
> I'd like to not call "FT_Glyph_To_Bitmap()" but just do
> 'FT_New_Glyph()' on my own, but that always crashes. Why?
What does the debugger say? This might give a hint.
Are you sure that the memory allocation routine in your code is the
one used by FreeType? `FT_MEM_ALLOC` is an internal
On Thursday, 20 July 2023 at 01:41:51 BST, Alexei Podtelezhnikov
wrote:
> > > Hin-Tak,
> >
> > > This is probably both a spec question & a technical question. What is the
> > > recommendation for COLRv1 when the rendering target media is not capable
> > > of color?
> >
> >
> Alpha
On Wednesday, 19 July 2023 at 05:55:20 BST, Werner LEMBERG
wrote:
> Different colour schemes are supported; the question is about
> defaults. For example, let's assume that a font contains color
> schemes A and B, the latter suitable for (most) color-blind people.
> Let's further
It took less than an hour of quick hack to get rid of librsvg and replace it
with Adobe Native + its cairo backend from Suziki san.
There is a rendering bug filed
ashttps://github.com/adobe/svg-native-viewer/issues/185
I said it is between librsvg and skia.
The code diff is
On Thursday, 20 July 2023 at 09:04:09 BST, Brad Neimann
wrote:
> > Perhaps it is easier just to show you what I have - this is already
> > functional and I can even switch COLRv1 palettes in ftgrid
> > (screenshots the usual place).
> …and where is this ‘usual place’? I can’t see
> about percentages, i runned the bench with -c 200 to have instant
> results for development process. here in the benchmark file
> attached, it made more acceptable result when increased the -c flag
> to 2000.
This is much better, thanks! However, there are still tests which
have a difference
Thanks! This even answers some questions I was thinking about, but hadn't
asked.
I was wondering why I couldn't find any GSUB entries for combining
characters. In one font I dumped with ttx, there were entries doing the
opposite: mapping 'aacute' -> 'a' + 'acute'.
Since hinting glyphs that are
> Probably both approaches are wrong. I am asking that question both in terms
> of the spec and in terms of implementation details - what is the
> correct/recommended approach to render multi-layered 32-bit RGBA COLRv1 data
> to a non-colour target media?
My recommendation is to blend three
> Since hinting glyphs that are descendants of combining characters
> will help few fonts, what other ways does the database need to use
> the GSUB table? The only other use case I'm aware of are one to one
> substitutions providing alternate forms of a glyph.
Probably yes, but who knows. It
> Probably yes, but who knows. It would be nice to have a generic
> solution that completely covers the whole situation, and we never have
> to think about it again.
Right now, I don't understand the needs well enough to know what to
generalize or to test whether the general solution works well
> Right now, I don't understand the needs well enough to know what to
> generalize or to test whether the general solution works well
> enough. I'd rather start with specific use cases rather than a
> general solution with unclear goals.
Well, there are no 'unclear goals': the general solution
14 matches
Mail list logo
