Hi,
I wanted to briefly discuss about the SVG Rendering Library. It's necessary
to do this before we can move on to discuss the callback hooks design. This
email doesn't have any questions. It is just to inform you guys about my
recent findings and also take feedback and get my mistakes and
miscon
> [...] we expect to do the following using the external SVG rendering
> library.
>
> 1. Get the pixel data of the whole SVG doc [...]
> 2. Get the bounding box of the whole doc (or the particular node) in
>SVG coordinates. [...]
I think all your conclusions are correct.
> *Resvg* can do mo
Sorry for lated response.
Werner LEMBERG wrote:
>> 1. Get the pixel data of the whole SVG doc [...]
>> 2. Get the bounding box of the whole doc (or the particular node) in
>>SVG coordinates. [...]
> OK. Toshiya-san and/or Moazin, what about svgnative?
The SVG document object in SVG Native V
For the sake of this explanation please assume that we are only talking
about the SVG documents which only contain one glyph and the whole document
is supposed to be rendered.
> [...] I want to know how they are required for SVG-OT.
>
Imagine we are using FreeType to render an apostrophe ` ' ` u
Dear Moazin,
On 2019/06/14 17:27, Moazin Khatri wrote:
> For the sake of this explanation please assume that we are only talking about
> the SVG documents which only contain one glyph and the whole document is
> supposed to be rendered.
OK!
> [...] I want to know how they are required for SVG-
Oh, I should add a few more.
> I'll look into how CFF glyphs behave, I am unaware of that at the moment. But
> if CFF glyphs also keep the positioning information in `slot->bitmap.buffer'
> by putting in empty pixels, then that is a possibility too.
It's not so hard for CFF or TrueType rasteriz
>
> Mmm, please let me ask a question. It is true that there are many un-inked
> pixel around apostrophe glyph. But, do we need to exclude surrounding
> un-inkeds pixel when we put some SVG glyph into slot->bitmap.buffer? If we
> pass an image with surrounding un-inked pixels to slot->bitmap.buffer
>If all of them have such, I would discuss such API is acceptable for SVG
>Native Viewer.
I meant, I would discuss whether such API is acceptable for SVG Native Viewer.
Regards,
mpsuzuki
On 2019/06/14 19:05, suzuki toshiya wrote:
> Oh, I should add a few more.
>
>> I'll look into how CFF glyp
Moazin Khatri wrote:
>> BTW, how resvg calculate the bitmap_left properties?
>
> It doesn't. But we can do it using it. For the sake of this explanation
> assume that no scaling is to be performed. We firstly use `resvg' to get a
> tight bounding box around the `inked' part. It will return us a
> Ummm. At present, I cannot find anything corresponding to
> cairo_recording_surface_ink_extents(), in Qt and Skia. I remember SkPath
> has
> something similar for a path object, but I cannot find in QPainter or
> SkCanvas.
> So, if there is serious requirement to calculate bitmap_left and
> bitma
Also, the reason why I was asking to ignore the case when an SVG document
has multiple glyphs with different IDs is, because in that case, things
become slightly simpler.
In case of `resvg', it automatically calculates the bounding box and
renders it so that all the `inked' part is in picture. It
Dear Moazin,
Please browse the attached SVG: which paints a big blue square (1024 x 1024),
and clip small circle at the center of it (r=64). How do you evaluate the
bitmap_left and bitmap_top? bitmap_left is 512 - 64 = 448? Or, bitmap_left is 0?
Moazin Khatri wrote:
> `Resvg' works with two graph
Sorry for the late reply.
What you've pointed out is a serious problem. Sorry for not being able to
understand this in your earlier email. :-(
Now after observing these problems what should be our direction of work
here? Should we store `un-inked' pixels in the slot->bitmap.buffer? or
should we m
Hi Toshiya,
I wanted to add a thought here.
For this email I am going to refer to "all of the code that the svg
rendering callback hooks point to" as the `rendering port'.
I think we can off-load all of the rendering and the `bitmap_left' and
`bitmap_top' extraction part to the rendering port. T
> I think we can off-load all of the rendering and the `bitmap_left'
> and `bitmap_top' extraction part to the rendering port. [...]
Do we really have to get the those values by actually rasterizing the
SVG stuff? I don't think this was the intention of the SVG
specification in OpenType, since
>
> I also don’t get it. What’s the problem? FreeType always does it from
> outlines. It allocates the bitmap memory. It happens to be tight in most
> cases because there is usually on-points at the extreme. Otherwise it is a
> bit larger.
Well, the same goes for most SVG rendering libraries. The
>> I think we can off-load all of the rendering and the `bitmap_left'
>> and `bitmap_top' extraction part to the rendering port. [...]
>
> Do we really have to get the those values by actually rasterizing the
> SVG stuff? I don't think this was the intention of the SVG
> specification
I also
Alexei A Podtelezhnikov, PhD
On Jun 15, 2019, at 12:12, Moazin Khatri wrote:
>> I also don’t get it. What’s the problem? FreeType always does it from
>> outlines. It allocates the bitmap memory. It happens to be tight in most
>> cases because there is usually on-points at the extreme. Otherw
>> I also don’t get it. What’s the problem? FreeType always does it from
>> outlines. It allocates the bitmap memory. It happens to be tight in most
>> cases because there is usually on-points at the extreme. Otherwise it is a
>> bit larger.
>
> Well, the same goes for most SVG rendering libra
Dear Moazin, Werner and Alex,
Sorry, I would be slow for a week because of my attendance to a foreign
meeting, please allow me to be unable to respond your questions timely.
As Werner questioned, I'm wondering what kind of the utilization of the
(precise) boundingbox of SVG glyph is assumed by
>
> [...] , it sounds as if the fonts should be designed as the metric values
> from TrueType or CFF glyphs could be used as if they are same for SVG
> glyphs.
>
THIS!
If that's the case, it is going to solve the whole problem I think. :) I
have a few OT-SVG fonts, I shall check this tomorrow.
B:
>> [...] , it sounds as if the fonts should be designed as the metric
>> values from TrueType or CFF glyphs could be used as if they are
>> same for SVG glyphs.
>
> THIS! If that's the case, it is going to solve the whole problem I
> think. :)
I also believe that this is the route to go.
I am investigating it! :)
On Sun, Jun 16, 2019 at 9:18 PM Werner LEMBERG wrote:
>
> >> [...] , it sounds as if the fonts should be designed as the metric
> >> values from TrueType or CFF glyphs could be used as if they are
> >> same for SVG glyphs.
> >
> > THIS! If that's the case, it is going
23 matches
Mail list logo
