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 i
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
___
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
Free
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 b
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 sho
Hi,
Kind of neither and both.
1 - I know of a small svg lib based on cairo, which is used by the netsurf
browser.
2 - in the context of enabling freetype to support svg font rendering, I was
wondering if this lib was considered? I don't know "how much" it is required
to add to this sv
On Wed, May 08, 2019 at 12:12:50PM +, suzuki toshiya wrote:
> As far as I can remember, libsvgtiny was not discussed in the thread for
> SVG-OT support. I didn't know the exist of libsvgtiny, I must thank you
> for giving the information.
Hi,
This is why I did jump into the thread, to give th
On Wed, May 08, 2019 at 03:34:22PM -0400, Alexei Podtelezhnikov wrote:
> > That said, I am wondering if the expressive power of freetype internal
> > vector
> > code could satisfy the requirements of the font svg rendering. Because that
> > would reduce the external dependency to some xml parser, t
On Sat, May 11, 2019 at 06:14:55AM +0200, Werner LEMBERG wrote:
> On the other hand, I want to have a configure-time default so that it
> is only necessary to explicitly set hooks for non-default SVG
> libraries (or if the default SVG library is not found at configure
> time). This would allow app
On Sat, May 11, 2019 at 01:09:16PM +0200, Werner LEMBERG wrote:
> What do you mean with `SDK'?
Software Developement Kit (C toolchain, GNU autotools, etc)
> Switching off the default SVG library would be an option for
> FreeType's `configure' script, for example:
>
> --with-svg=[yes|no|auto]
>
On Sat, May 11, 2019 at 09:49:57PM +0200, Werner LEMBERG wrote:
> This is the plan, yes. SVG data will be sent to the external SVG
> library, which will return a bitmap or pixmap. I don't want to blow
> up FreeType with graphics code.
Ok. Then it would mean even the restricted "font svg" is exce
On Sat, May 11, 2019 at 10:46:38PM +0200, Werner LEMBERG wrote:
> I don't understand what you want to say. The OpenType specification
> defines what the `SVG' table holds. It's not me who is going to
> decide what kind of SVG data is valid in fonts.
:) It was just to bounce back on what Alexei P
On Fri, Dec 27, 2019 at 12:58:22PM +0100, Werner LEMBERG wrote:
> For most outline fonts, it is not possible to get exact glyph
> dimensions in advance (exception: the font contains an `hdmx' table
> that holds horizontal, device-dependent information for selected pixel
> sizes). In other words, y
On Fri, Dec 27, 2019 at 07:00:58PM +0100, Werner LEMBERG wrote:
> As the name of such font says, all glyphs have the same advance width.
> However, there is *zero* guarantee that the outline stays in a certain
> rectangle that is as wide as this advance width. For example, imagine
> a slanted mono
14 matches
Mail list logo
