SVG path not Unique for character > 25
Forked from https://github.com/leifgehrmann/pangocairocffi/issues/19
I'm from Manim were we this project for rendering Text.Manim
uses cffi binding for Pango and Cairo namely,
- pangocffi==0.8.0
- pangocairocffi==0.4.0
- cairocffi==1.2.0
We have a method to create an SVG file using pangocffi and later that SVG file is parsed in as Mobject(more like numpy array). It is made so that each letter would represent a submobject(again a numpy array) where the user can manipulate the submobject also. Now, the problem here is the SVG file created using pangocffi and cairocffi, the number of SVG path != number of character
for total lenth of character is greater than 25(>25
). <25
works like a charm.
On carefully examining it, it look like the path string of the last two character are concadinated (which is unexpected) and it looks like a bug for me. I expected that the length of string = length of paths - number of space and line break
but it wasn't so, for string length>25
, it was one character less,
Reproducing Code
import cairocffi
import pangocffi
import pangocairocffi
surface = cairocffi.SVGSurface("bug.svg", 600, 400)
context = cairocffi.Context(surface)
context.move_to(10, 10)
layout = pangocairocffi.create_layout(context)
layout.set_width(pangocffi.units_from_double(600))
fontdesc = pangocffi.FontDescription()
fontdesc.set_size(pangocffi.units_from_double(10))
layout.set_font_description(fontdesc)
layout.set_text("#This is some custom confl")
pangocairocffi.show_layout(context, layout)
surface.finish()
After running this I get a SVG file, bug.zip
, packed in a zip file attached at end,
Here, there is 26 character on the whole and it has 4 white spaces. But there are only 25 paths defined as below.
<g style="fill:rgb(0%,0%,0%);fill-opacity:1;">
<use xlink:href="#glyph0-1" x="10" y="22"/>
[...]
<use xlink:href="#glyph0-14" x="186" y="22"/>
</g>
Where it should 26 though. On further examining I found that
<symbol overflow="visible" id="glyph0-14">
<path style="stroke:none;" d="M 4.773438 -10.128906 L 7.355469 -10.128906 L 7.355469 -0.691406 L 8.496094 -0.691406 L 8.496094 0 L 5.011719 0 L 5.011719 -0.691406 L 6.160156 -0.691406 L 6.160156 -9.441406 L 4.757813 -9.441406 C 4.050781 -9.4375 3.550781 -9.296875 3.261719 -9.015625 C 2.96875 -8.730469 2.824219 -8.25 2.824219 -7.570313 L 2.824219 -6.921875 L 4.746094 -6.921875 L 4.746094 -6.222656 L 2.824219 -6.222656 L 2.824219 -0.691406 L 3.957031 -0.691406 L 3.957031 0 L 0.480469 0 L 0.480469 -0.691406 L 1.628906 -0.691406 L 1.628906 -6.222656 L 0.480469 -6.222656 L 0.480469 -6.921875 L 1.628906 -6.921875 L 1.628906 -7.546875 C 1.628906 -8.417969 1.886719 -9.066406 2.40625 -9.492188 C 2.921875 -9.914063 3.710938 -10.125 4.773438 -10.128906 Z M 4.773438 -10.128906 "/>
</symbol>
the above one represents two characters fl
. But it should actually be one character l
alone. This is the main issue which simply broke many parts of Manim Code.
Pango Version:
>>> pangocffi.pango_version_string()
'1.46.1'
On my Windows 10, with Pango provided by msys2 project.
Now the question is whether this is a bug or is this expected? Sorry, I couldn't a C example file because I just a begginer there.