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
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
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
> 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
>
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
>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
>
> 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
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
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
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 ` ' `
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
11 matches
Mail list logo
