Dear Sylvain,
Excuse me, please let me confirm your intention.
Which is the background of "I cannot answer this question by myself".
a) libsvgtiny should be audited from now, because we (including both
of you and me) have not audited.
b) we (including both of you and me) don't know the required
On Wed, May 08, 2019 at 01:44:39AM +, suzuki toshiya wrote:
> However, my impression on libsvgtiny is... its range of the features
> might be narrower than SVG Native: I think it does not support
> the image elements in SVG. Am I misunderstanding?
Hi,
This is for this very reason this lib
Dear Sylvain,
Thank you for the introduction of libsvgtiny in netsurf browser.
I think I've once visited netsurf website, but I was unaware that
it has their own SVG renderer.
Just I've checked the source, and, it's interesting to see that
netsurf has their own DOM support library based on
On Tue, May 7, 2019 at 9:46 AM Werner LEMBERG wrote:
>
> > What happened to the resvg (Rust library) idea?
>
> It's not completely off the table, but it seems to me that `svgnative'
> is preferable.
>
Given that we want a pluggable renderer, the whole discussion is moot. For
pangocairo, we're
> What happened to the resvg (Rust library) idea?
It's not completely off the table, but it seems to me that `svgnative'
is preferable.
> Also, note that the small SVG Native comes at a cost that it doesn't
> support much...
This remark I don't understand. What exactly do you mean with
What happened to the resvg (Rust library) idea? At any rate, I agree SVG
renderrer should be pluggable by client and not fixed in FreeType.
Also, note that the small SVG Native comes at a cost that it doesn't
support much...
On Tue, May 7, 2019 at 8:27 AM wrote:
> On Tue, May 07, 2019 at
On Tue, May 07, 2019 at 07:53:22PM +0500, Moazin Khatri wrote:
> > I wonder if a re-implementation is a good idea.
Since it's to get rid of a c++ toolchain dep, it's always a good idea.
Maintenance will occur naturally if svg based fonts get significant traction.
The good new is that it seems to
On Tue, May 07, 2019 at 03:53:55PM +0200, Werner LEMBERG wrote:
> https://github.com/adobe/svg-native-viewer/
it's c++. :(
and it seems it does not have even the decency to provide a C api :(
regards,
--
Sylvain
___
Freetype-devel mailing list
On Tue, May 07, 2019 at 03:53:55PM +0200, Werner LEMBERG wrote:
> https://github.com/adobe/svg-native-viewer/
forgot this! I skimed through the project (then I may be heavily wrong) and it
seems small enough to allow a re-implementation.
--
Sylvain
Dear Sylvain,
> Which svg renderer will be used? Which XML parser will be used? Because, that
> could add heavy SDK deps to freetype.
Very very good point, I sympathize you strongly.
At present, I don't suggest to link SVG renderer to libfreetype directly.
For sbix color font support, libpng is
> Which svg renderer will be used? Which XML parser will be used? Because,
> that
> could add heavy SDK deps to freetype.
There are constraints that make this project possible. These some quotes
from https://docs.microsoft.com/en-us/typography/opentype/spec/svg
- Adoption of SVG for use in
>> Adding support for OpenType SVG Colored Fonts to FreeType
>
> Which svg renderer will be used?
Whatever the system has, see below.
> Which XML parser will be used?
With a very high probability it will be `svgnative', contributed by
Adobe:
https://github.com/adobe/svg-native-viewer/
On Tue, May 07, 2019 at 06:24:41AM +0200, Werner LEMBERG wrote:
> (3) Moazin Khatti: Adding support for OpenType SVG Colored Fonts to
> FreeType
Hi,
Which svg renderer will be used? Which XML parser will be used? Because, that
could add heavy SDK deps to freetype.
librsvg
13 matches
Mail list logo
