> The "fonts" dir at
> https://github.com/unicode-org/text-rendering-tests now contains a
> few TestSVG*.otf fonts, including one with multiple glyphs in a
> single SVG doc (and one with gzip'd SVG).
Thanks for telling us!
Werner
___
The "fonts" dir at https://github.com/unicode-org/text-rendering-tests now
contains a few TestSVG*.otf fonts, including one with multiple glyphs in a
single SVG doc (and one with gzip'd SVG).
Thanks to Adobe Type's Miguel Sousa for contributing these.
The repo above is the one blessed by
> We'll provide a test font that has multiple glyphs within an SVG
> doc. I agree that this should be in a test suite repo.
Excellent, thanks!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
We'll provide a test font that has multiple glyphs within an SVG doc. I agree
that this should be in a test suite repo.
We at Adobe Type don't know of shipping fonts that use this facility, and
Fontself Maker doesn't generate fonts using it. It will be an interesting
subroutizer project for
>> Do you think that this kind of `caching' should be done on the
>> FreeType side or on the SVG side?
>
> That's interesting question. Ideally font is memory-mapped and
> FreeType just returns a pointer to the SVG document, so there's no
> copying involved. Then the client can do any caching
On Tue, May 14, 2019 at 11:42 PM Werner LEMBERG wrote:
>
> > Realistically, not many fonts combine multiple glyphs into the same
> > SVG documents, for obvious reasons of workflow: fonts are built out
> > of a collection of standalone SVGs much more often than hand-curated
> > SVG documents
On Tue, May 14, 2019 at 11:24 PM Werner LEMBERG wrote:
>
> > If you read the OT-SVG table spec, multiple glyphs can refer to the
> > same SVG document. Then for a glyph eg. 1234, client is expected to
> > render the element with id "glyph1234" in the referenced SVG
> > document.
>
> OK, thanks.
> If you read the OT-SVG table spec, multiple glyphs can refer to the
> same SVG document. Then for a glyph eg. 1234, client is expected to
> render the element with id "glyph1234" in the referenced SVG
> document.
OK, thanks. Since my SVG knowledge is virtually zero, the following
question
On Tue, May 14, 2019 at 9:42 AM Werner LEMBERG wrote:
>
> >> Could you tell me more about "all the current energye is going in
> >> the wrong direction"? Do you think "spending much energy for the
> >> discussion which is not so much important"? Or, do you think
> >> "trying to implement
>> Could you tell me more about "all the current energye is going in
>> the wrong direction"? Do you think "spending much energy for the
>> discussion which is not so much important"? Or, do you think
>> "trying to implement something in wrong design"?
>
> (Replying to your and Werner's
On Tue, May 14, 2019 at 9:17 AM suzuki toshiya
wrote:
> Dear Behdad,
>
> Alexei wrote:
> > Whatever external SVG renderer you choose, please use FT_Renderer
> facility to hook it up with FreeType instead of creating a set of SVG
> specific functions: an SVG glyph should be tagged as
Dear Behdad,
Alexei wrote:
> Whatever external SVG renderer you choose, please use FT_Renderer facility to
> hook it up with FreeType instead of creating a set of SVG specific functions:
> an SVG glyph should be tagged as FT_GLYPH_FORMAT_SVG, which is then picked up
> by the dedicated SVG
>> Whatever external SVG renderer you choose, please use FT_Renderer
>> facility to hook it up with FreeType instead of creating a set of
>> SVG specific functions: an SVG glyph should be tagged as
>> FT_GLYPH_FORMAT_SVG, which is then picked up by the dedicated SVG
>> FT_Renderer with hooks to
On Tue, May 14, 2019 at 8:37 AM Alexei Podtelezhnikov
wrote:
>
> > 3. *How much work to do make it work with FreeType*: Does it need a
>> >C API wrapper?
>>
>> Yes.
>
>
> Whatever external SVG renderer you choose, please use FT_Renderer facility
> to hook it up with FreeType instead of
> > 3. *How much work to do make it work with FreeType*: Does it need a
> >C API wrapper?
>
> Yes.
Whatever external SVG renderer you choose, please use FT_Renderer facility
to hook it up with FreeType instead of creating a set of SVG specific
functions: an SVG glyph should be tagged as
For completeness, I’d like to add that the license should also be a
criterion. I think librsvg is GPL+LGPL, resvg is MPL, and the Adobe SVG
Native viewer is Apache 2.
It’s worth realizing that SVG actually originated in the late 1990s with
strong participation from Adobe, and the Adobe SVG Viewer
>> 3. *How much work to do make it work with FreeType*: Does it need a
>>C API wrapper?
>
> Yes.
This is really the main criterium IMO; as discussed two days ago, as long as
the library is shipped as a prebuilt code blob for most Linux distros, that's
perfect and no one needs to care about
> The criterion I have in mind is based on the following points:
>
> 1. *SVG Features*: This is very important. Anything that doesn't
>support all of the features of `SVG Native' specification would
>probably not be considered. The more features supported, the
>better.
On the other
Hi folks,
As you would already know, we need an SVG rendering library that we can set
as the default one for FreeType. Over the next few days and especially this
weekend, I'll be trying to audit the major available SVG rendering
libraries (that I know about so far) and comparing them on the basis
Hi folks,
As you would already know, we need an SVG rendering library that we can set
as the default one for FreeType. Over the next few days and especially this
weekend, I'll be trying to audit the major available SVG rendering
libraries (that I know about so far) and comparing them on the basis
20 matches
Mail list logo
