I’m in the work of improving Lottie exporter but that’s probably other history…
Well, I found out that text size doesn’t match what it should… or I still don’t understand “image size” and “image area” concepts.
Please, have a look at the following screenshot:
Image area is 600/60=10 units, that is, image size equals image area, that is, “zoom” is 1 (no zoom)
I made a text layer and placed in the center, center alignment and even orientation set to (0.5,0.5)
I would expect the following behavior: if I set text size to (200,200) pixels then the size of capital letter should be exactly (or very close, I know it depends on the glyph you choose) to that 200x200px grey square, doesn’t it?
It doesn’t match and only manually i find that setting it to (140,140) then they look to match… why?
Can you provide the test file?
I don’t quite understand what the problem is since you didn’t provide the screenshot that shows the difference in sizes.
Here’s mine:
Both circle and text layer (font: Times New Roman) have size of 1u (60px) and do look pretty close in size. Canvas size is standard: 480x270, span 9.1788.
Thanks for taking your time trying to help me (or to find a bug… I still don’t know how to name it)
I thought the screenshot was going to be enough to understand the situation, anyway, attached is the .sif file for testing: axa.zip (1,1 KB)
Anyway, pay attention to my screenshot as the square is 200x200px while the text size is 140px… to me this is a big difference.
Even your example shows a difference in size, maybe around a 20-25% or error…
Anyway, I’m trying to figure this out because I’m improving the Lottie exporter and I’m having trouble exporting text size as it should be, I mean, text size should be the same in our Synfig projects and in the exported Lottie file…
What I’ve been testing is that there is a difference of exactly (or very close) 0,7 units, that is, text is 0,3 smaller that it should be. It can be solved by dividing the text size by 0,7 and then you get a better approximation. In your example 60/0,7=85,9px
OK, I am not a developer and don’t care much about text (if it shows then I am good) so I thought that the small difference in size is just, you know, how it should be, because of the different glyphs or what have you.
I checked the code, and before rendering the text it multiplies its size by 2. Here’s a snippet of that code:
I changed the constant to 3, recompiled Synfig and the result looks like this now:
The size for circles and text is 0.9u, the fonts are your typical ones from Windows (starting from top-left): Arial, Consolas, Courier New, Lucida Console, Tahoma, and Times New Roman.
As you can see, the result seems to be better but some fonts do overshoot (are bigger than the circle of the same size). Again, I am not a developer, I do not know the full algorithm behind the font rendering, this is just my quick test.
Here’s the test-case file I used: FontSize.sifz (1.7 KB)
Yes, I algo got here this evening and I don’t know why that 2 factor comes from… I’m still intrigued about how to really calculate a right font height…
Looking deeply about how fonts are defined, I found this:
And what seems clear is that the font height (or commonly called size) is the maximum space a font can take, that is, the length between descender and ascender.
After some experiments with our files, it looks like Synfig takes the “x-height” as the font height which is wrong… the theory says that font height is usually double the size of x-height: Grid set to 100px (and text size as well):
If that is true, Synfig font size should be half of the size that is already taking now, that is, the number 2 we found in he code should be deleted to let users set a right font size… am I right?
Wait, I am stoopid… Shouldn’t surprise anyone but still…
Parameter ‘radius’ in Circle layer means diameter it confused me… Jeez, send me back to school. You also confused me with your initial post - why 200px x 200px when it should have been 0px x 200px? Synfig starts drawing from 0.
Seems to be so. The result without multiplication is this:
Size of text and grid is 1u, text orientation is 0,0, example font is Arial.
Although, without multiplication, not all text renders correctly, for example text “Synfig” would render as “Syng”. We need to hear from actual developers now.
Umm, I see it correctly: radius means radius but your circle will be 2*radius (diameter), hehehe. I don’t know why you said it…
It’s not really a confusion, the real size of the square was 200x200px, no matter where Synfig starts drawing (where its origin is…).
Well, I would bet it was a confusion and the text size should be changed “without multiplication” but, as you say, developers (@rodolforg, @ice0, @mohamed.Adhamc, @BobSynfig…) have the last word.
Yeah, it was on me, sorry. Somehow I was thinking that squares were supposed to be the same size as grid, don’t know why I thought that…
Anyway, I do not know why multiplication was there in the first place, it is there since the very beginning - 0.64.x branch.
Wow, I completely missed your response.
Not sure, here’s how it looks with your example (no multiplication):
The capital ‘A’ doesn’t overshoot, but ‘c’ does extend beyond its boundaries. Perhaps its intentional.
Yeah, that was most likely the original intention to get something acceptable without thinking much. Personally I don’t have a problem with it but if we can render text in a more proper way it would be better of course.
