Hi,
in IRC there was a discussion about the font size setting and I have to admit that I don't understand it.
The tooltip says the value is in pt, which (according to the CSS specs) is 1/72th of an inch.
Inkscape now uses a DPI of 96 to convert to/from pixels.
When I type some text in 72 pt and then select the object the control bar tells me it's size was 6.72 mm, which would be 0.264566929134 inch [0] and that is 25.4 pixel [1], which is what I can see in the XML being stored.
The part I don't understand is how that value relates to the initial 72 pt? And is it a coincidence that the final result of 25.4 is the conversion factor inch/mm?
Some clarification or links to documentation would be appreciated.
Tobias
PS: Would it be possible to fix the font size box to show "nice" values and not some rounded numbers? Maybe just storing the pt value typed by the user along the converted px value and showing that? Or doing it the right way and putting the pt verbatim into the SVG as it used to be done? Currently it's really hard to do any serious work that involves text.
[0] 6.72 / 25.4 = 0.264566929134 [1] 0.264566929134 * 96 = 25,3984251969 ~ 25.4
Hi Tobias. Is based, in a preferences option.I have plans to improve it, based in a su_v and Gez work in a bug. https://bugs.launchpad.net/inkscape/+bug/ 1422926
Cheers, Jabier.
El jue, 18-02-2016 a las 15:27 +0100, Tobias Ellinghaus escribió:
Hi,
in IRC there was a discussion about the font size setting and I have to admit that I don't understand it.
The tooltip says the value is in pt, which (according to the CSS specs) is 1/72th of an inch.
Inkscape now uses a DPI of 96 to convert to/from pixels.
When I type some text in 72 pt and then select the object the control bar tells me it's size was 6.72 mm, which would be 0.264566929134 inch [0] and that is 25.4 pixel [1], which is what I can see in the XML being stored.
The part I don't understand is how that value relates to the initial 72 pt? And is it a coincidence that the final result of 25.4 is the conversion factor inch/mm?
Some clarification or links to documentation would be appreciated.
Tobias
PS: Would it be possible to fix the font size box to show "nice" values and not some rounded numbers? Maybe just storing the pt value typed by the user along the converted px value and showing that? Or doing it the right way and putting the pt verbatim into the SVG as it used to be done? Currently it's really hard to do any serious work that involves text.
[0] 6.72 / 25.4 = 0.264566929134 [1] 0.264566929134 * 96 = 25,3984251969 ~ 25.4
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hello,
It would be very useful too to be able to give a precise line height in pts or px like in CSS. (Of course one should keep the choice of working with %) ivan
Le Jeudi 18 février 2016 17h18, Jabier Arraiza <jabier.arraiza@...360...2893...> a écrit :
Hi Tobias. Is based, in a preferences option.I have plans to improve it, based in a su_v and Gez work in a bug. https://bugs.launchpad.net/inkscape/+bug/ 1422926
Cheers, Jabier.
El jue, 18-02-2016 a las 15:27 +0100, Tobias Ellinghaus escribió:
Hi,
in IRC there was a discussion about the font size setting and I have to admit that I don't understand it.
The tooltip says the value is in pt, which (according to the CSS specs) is 1/72th of an inch.
Inkscape now uses a DPI of 96 to convert to/from pixels.
When I type some text in 72 pt and then select the object the control bar tells me it's size was 6.72 mm, which would be 0.264566929134 inch [0] and that is 25.4 pixel [1], which is what I can see in the XML being stored.
The part I don't understand is how that value relates to the initial 72 pt? And is it a coincidence that the final result of 25.4 is the conversion factor inch/mm?
Some clarification or links to documentation would be appreciated.
Tobias
PS: Would it be possible to fix the font size box to show "nice" values and not some rounded numbers? Maybe just storing the pt value typed by the user along the converted px value and showing that? Or doing it the right way and putting the pt verbatim into the SVG as it used to be done? Currently it's really hard to do any serious work that involves text.
[0] 6.72 / 25.4 = 0.264566929134 [1] 0.264566929134 * 96 = 25,3984251969 ~ 25.4
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
After thinking about it a little more and playing with Inkscape I think I know what is happening.
Two observations:
(1) What Inkscape calls "Font size" is the line height at 100%. (2) What Inkscape calls "Spacing between lines" is the line height wrt. font size.
Both of those are wrong. To see what I mean have a look at the attached image.
In the attached image the text is set to be 72 pt big, which equals 1 inch. With the "line spacing" at 1 (100%) the lines are exactly 1 inch apart (red lines). When the "line spacing" is set to 0 the thing on the right can be seen. That clearly shows that it's not the line spacing but the line height that is set by that setting. When the space is 0 the two lines should almost touch but not overlap. As I wrote in my last mail, Inkscape gives a value of 6.72 mm in the control bar. That seems to be the actual line spacing, at least it's what I can see as non-occupied space between the text lines (green lines).
Can anyone confirm that Inkscape makes text too small (1) and uses a mislabeled (and in practice rather useless) line spacing setting (2)? At least the latter seems obvious to me.
I hope we can sort this out to make Inkscape suitable for serious typographic work. Or, what is also possible, educate me about where I am wrong.
Thanks for your time Tobias
Am Donnerstag, 18. Februar 2016, 15:27:14 schrieb Tobias Ellinghaus:
Hi,
in IRC there was a discussion about the font size setting and I have to admit that I don't understand it.
The tooltip says the value is in pt, which (according to the CSS specs) is 1/72th of an inch.
Inkscape now uses a DPI of 96 to convert to/from pixels.
When I type some text in 72 pt and then select the object the control bar tells me it's size was 6.72 mm, which would be 0.264566929134 inch [0] and that is 25.4 pixel [1], which is what I can see in the XML being stored.
The part I don't understand is how that value relates to the initial 72 pt? And is it a coincidence that the final result of 25.4 is the conversion factor inch/mm?
Some clarification or links to documentation would be appreciated.
Tobias
PS: Would it be possible to fix the font size box to show "nice" values and not some rounded numbers? Maybe just storing the pt value typed by the user along the converted px value and showing that? Or doing it the right way and putting the pt verbatim into the SVG as it used to be done? Currently it's really hard to do any serious work that involves text.
[0] 6.72 / 25.4 = 0.264566929134 [1] 0.264566929134 * 96 = 25,3984251969 ~ 25.4
Hi again,
sorry for the noise. I think I was wrong in some points. It seems that font size is actually correct, however the line spacing is strange. It's either the line height, or it's off by one. That confused me enough to get the font size stuff wrong it seems.
That still leaves the question what Inkscape means with the 6.72 mm in the control bar. It doesn't seem to have any relation to the actual font settings. Unless, it's the pixel size of the font as stored in the XML (25.4 px in case of the default A4 template where viewbox/size results in a scaling factor of 1px = 1mm) converted back to real world units without taking the scaling factor into consideration but just using the default 96 DPI to go from pixel to inch and then turning that into mm? That would be a bug I guess?
Tobias
Am Donnerstag, 18. Februar 2016, 18:08:25 schrieb Tobias Ellinghaus:
After thinking about it a little more and playing with Inkscape I think I know what is happening.
Two observations:
(1) What Inkscape calls "Font size" is the line height at 100%. (2) What Inkscape calls "Spacing between lines" is the line height wrt. font size.
Both of those are wrong. To see what I mean have a look at the attached image.
In the attached image the text is set to be 72 pt big, which equals 1 inch. With the "line spacing" at 1 (100%) the lines are exactly 1 inch apart (red lines). When the "line spacing" is set to 0 the thing on the right can be seen. That clearly shows that it's not the line spacing but the line height that is set by that setting. When the space is 0 the two lines should almost touch but not overlap. As I wrote in my last mail, Inkscape gives a value of 6.72 mm in the control bar. That seems to be the actual line spacing, at least it's what I can see as non-occupied space between the text lines (green lines).
Can anyone confirm that Inkscape makes text too small (1) and uses a mislabeled (and in practice rather useless) line spacing setting (2)? At least the latter seems obvious to me.
I hope we can sort this out to make Inkscape suitable for serious typographic work. Or, what is also possible, educate me about where I am wrong.
Thanks for your time Tobias
Am Donnerstag, 18. Februar 2016, 15:27:14 schrieb Tobias Ellinghaus:
Hi,
in IRC there was a discussion about the font size setting and I have to admit that I don't understand it.
The tooltip says the value is in pt, which (according to the CSS specs) is 1/72th of an inch.
Inkscape now uses a DPI of 96 to convert to/from pixels.
When I type some text in 72 pt and then select the object the control bar tells me it's size was 6.72 mm, which would be 0.264566929134 inch [0] and that is 25.4 pixel [1], which is what I can see in the XML being stored.
The part I don't understand is how that value relates to the initial 72 pt? And is it a coincidence that the final result of 25.4 is the conversion factor inch/mm?
Some clarification or links to documentation would be appreciated.
Tobias
PS: Would it be possible to fix the font size box to show "nice" values and not some rounded numbers? Maybe just storing the pt value typed by the user along the converted px value and showing that? Or doing it the right way and putting the pt verbatim into the SVG as it used to be done? Currently it's really hard to do any serious work that involves text.
[0] 6.72 / 25.4 = 0.264566929134 [1] 0.264566929134 * 96 = 25,3984251969 ~ 25.4
Hi,
I'll try to give a short summary of font-size and line-height in Inkscape (and SVG).
First, fixed units (pt, cm, in, etc.) should not be used inside an SVG file. This is the recommendation of both the SVG and CSS working groups. Fixed units were intended to allow one to specify a length on an output device so that 1in would result in a real length of 1 inch on any monitor. This never worked in practice as monitors rarely reported their true scaling factor. Eventually the CSS working group decided to define fixed lengths in terms of the px unit: thus we have 1in defined to be equal to 96px. In SVG this is translated as 1in = 96 user units since the initial value of a user unit is 1px. Now imagine that you have an SVG with a width of 10in, a height of 10in, and a view box of 0,0,10,10. This sets one user unit to be equal to one "real world" inch. If you specify a font size of 12pt inside the SVG file, it results in a "real world" font size of 16 inches (12pt = 16px but 1px, i.e. user unit is one inch in real world terms).
Also note that the initial 'user unit' is one px. Scaling will change the value of the 'user unit' so, for example, if the scale factor is 0.5, text with a 1in font size would be rendered with a size of 0.5in.
Inkscape specifies 'font-size' internally in terms of user units (for the reason given above). What is shown in the GUI depends on the setting of the "Text unit" preference found in the Inkscape Preference dialog under the Text tool tab. The default value was changed to "pt" from "px" so by default the numerical value stored in the SVG file is 4/3 the value displayed in the Text tool tool bar. This creates rounding errors (I do not like this change).
SVG/CSS dictate that the font size ('font-size' property) is based on the 'em box' which is the 'accent' value + the 'decent' value as given in the font. This is NOT the Cap Height (the green line in your PNG). Some fonts include a value for 'leading'. This is ignored.
The interline spacing is given by the 'line-height' property. Line height is the distance from one baseline to the next baseline. The Inkscape GUI currently allows setting this value only based on a percentage of the 'font-size'. A value of '2' means 200% (the value stored in the SVG file) so in the simplest case if the 'font-height' is 10px, the interline spacing will be 20px. In reality it can be much more complicated. CSS dictates that the line height is calculated relative to the maximum 'ascent' and the maximum 'descent' of all the glyphs in a line of text. If the line consists of glyphs from the same font at the same font size then this is the simplest case as just described. But if the glyphs are from different fonts or have different font sizes then one must find the maximum ascent and the maximum descent (independently) by examining all the glyphs in the line one by one.
Tav
On Fri, 2016-02-19 at 12:45 +0100, Tobias Ellinghaus wrote:
Hi again,
sorry for the noise. I think I was wrong in some points. It seems that font size is actually correct, however the line spacing is strange. It's either the line height, or it's off by one. That confused me enough to get the font size stuff wrong it seems.
That still leaves the question what Inkscape means with the 6.72 mm in the control bar. It doesn't seem to have any relation to the actual font settings. Unless, it's the pixel size of the font as stored in the XML (25.4 px in case of the default A4 template where viewbox/size results in a scaling factor of 1px = 1mm) converted back to real world units without taking the scaling factor into consideration but just using the default 96 DPI to go from pixel to inch and then turning that into mm? That would be a bug I guess?
Tobias
Am Donnerstag, 18. Februar 2016, 18:08:25 schrieb Tobias Ellinghaus:
After thinking about it a little more and playing with Inkscape I think I know what is happening.
Two observations:
(1) What Inkscape calls "Font size" is the line height at 100%. (2) What Inkscape calls "Spacing between lines" is the line height wrt. font size.
Both of those are wrong. To see what I mean have a look at the attached image.
In the attached image the text is set to be 72 pt big, which equals 1 inch. With the "line spacing" at 1 (100%) the lines are exactly 1 inch apart (red lines). When the "line spacing" is set to 0 the thing on the right can be seen. That clearly shows that it's not the line spacing but the line height that is set by that setting. When the space is 0 the two lines should almost touch but not overlap. As I wrote in my last mail, Inkscape gives a value of 6.72 mm in the control bar. That seems to be the actual line spacing, at least it's what I can see as non-occupied space between the text lines (green lines).
Can anyone confirm that Inkscape makes text too small (1) and uses a mislabeled (and in practice rather useless) line spacing setting (2)? At least the latter seems obvious to me.
I hope we can sort this out to make Inkscape suitable for serious typographic work. Or, what is also possible, educate me about where I am wrong.
Thanks for your time Tobias
Am Donnerstag, 18. Februar 2016, 15:27:14 schrieb Tobias Ellinghaus:
Hi,
in IRC there was a discussion about the font size setting and I have to admit that I don't understand it.
The tooltip says the value is in pt, which (according to the CSS specs) is 1/72th of an inch.
Inkscape now uses a DPI of 96 to convert to/from pixels.
When I type some text in 72 pt and then select the object the control bar tells me it's size was 6.72 mm, which would be 0.264566929134 inch [0] and that is 25.4 pixel [1], which is what I can see in the XML being stored.
The part I don't understand is how that value relates to the initial 72 pt? And is it a coincidence that the final result of 25.4 is the conversion factor inch/mm?
Some clarification or links to documentation would be appreciated.
Tobias
PS: Would it be possible to fix the font size box to show "nice" values and not some rounded numbers? Maybe just storing the pt value typed by the user along the converted px value and showing that? Or doing it the right way and putting the pt verbatim into the SVG as it used to be done? Currently it's really hard to do any serious work that involves text.
[0] 6.72 / 25.4 = 0.264566929134 [1] 0.264566929134 * 96 = 25,3984251969 ~ 25.4
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Tavmjong Bah wrote
If you specify a font size of 12pt inside the SVG file, it results in a "real world" font size of 16 inches (12pt = 16px but 1px, i.e. user unit is one inch in real world terms).
My understanding is that 'pt' is an absolute unit i.e. 1/72 inch. So, IMHO it's wrong to consider the 4/3 ratio between px and pt to manage the pt unit and consider 'pt' as relative to the 'user unit'. The same reasoning could be done in a document where 1 'user unit' is 1 'mm' and one specifies a 1 inch measurement: 1 inch = 96 px = 96 mm !?! Inkscape is not behaving in this way now, and it should do the same with 'pt'.
-- View this message in context: http://inkscape.13.x6.nabble.com/How-does-font-size-work-tp4975578p4975604.h... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Am 19.02.2016 um 15:49 schrieb Tavmjong Bah:
First, fixed units (pt, cm, in, etc.) should not be used inside an SVG file. This is the recommendation of both the SVG and CSS working groups. Fixed units were intended to allow one to specify a length on an output device so that 1in would result in a real length of 1 inch on any monitor. This never worked in practice as monitors rarely reported their true scaling factor. Eventually the CSS working group decided to define fixed lengths in terms of the px unit: thus we have 1in defined to be equal to 96px. In SVG this is translated as 1in = 96 user units since the initial value of a user unit is 1px. Now imagine that you have an SVG with a width of 10in, a height of 10in, and a view box of 0,0,10,10. This sets one user unit to be equal to one "real world" inch. If you specify a font size of 12pt inside the SVG file, it results in a "real world" font size of 16 inches (12pt = 16px but 1px, i.e. user unit is one inch in real world terms).
I'm not sure if this recommendation is ideal?
While for pixel-based devices I totally understand the argumentation, SVG is not limited to them. For example I'm often preparing scientific figures with Inkscape for usage in printed media. This means that I set a fixed width/height of the document (in inch or cm) and want a fixed font size (usually specified in pt). Most publishers explicitly state the size of fonts that have to be used (in pt).
I guess in this case it would be preferable to have this exact value (e.g. 8 pt) specified in the SVG file instead of some "arbitrary" pixel value that is even dependent on the specification of the view box and might also round to some absurd decimal number (that in turn might round to an even more absurd pt value).
Correct me if I'm wrong, but I don't see how a pixel specification could be recommended in this case...
Best Regards, Eduard
Am Freitag, 19. Februar 2016, 15:49:59 schrieb Tavmjong Bah:
Hi,
Hi,
I'll try to give a short summary of font-size and line-height in Inkscape (and SVG).
thank you very much for your explanation. Most of which I already figured out, but the part about pt being non-fixed wasn't clear to me (and as others wrote, I think it's a bad decision).
[...]
Inkscape specifies 'font-size' internally in terms of user units (for the reason given above). What is shown in the GUI depends on the setting of the "Text unit" preference found in the Inkscape Preference dialog under the Text tool tab. The default value was changed to "pt"
Actually it isn't in all places, see below.
from "px" so by default the numerical value stored in the SVG file is 4/3 the value displayed in the Text tool tool bar. This creates rounding errors (I do not like this change).
Me neither. :)
SVG/CSS dictate that the font size ('font-size' property) is based on the 'em box' which is the 'accent' value + the 'decent' value as given in the font. This is NOT the Cap Height (the green line in your PNG). Some fonts include a value for 'leading'. This is ignored.
I know, no idea why I got that confused there.
The interline spacing is given by the 'line-height' property. Line height is the distance from one baseline to the next baseline. The Inkscape GUI currently allows setting this value only based on a percentage of the 'font-size'.
That is fine, however, the Inkscape GUI doesn't mention line height but line spacing. So it's actually off by 1. The look of the default "1" setting should be achieved by setting the GUI value to "0". Either that, or the tooltip should be changed to mention line height instead of spacing.
[...]
So, besides the wrong tooltip that caused much of my confusion there is also the status bar which shows the font name and size of selected objects. However, it
- uses the default display unit and not the font unit and - doesn't take the document's view box scaling (as described by you above) into account.
Attached you will find a patch to fix both. I am not sure if it's the right way to do it, it feels as if I mixed old C and new C++ API, but I couldn't find a pure C++ way to handle it.
Tav
Tobias
[...]
On Fri, 2016-02-19 at 22:39 +0100, Tobias Ellinghaus wrote:
Am Freitag, 19. Februar 2016, 15:49:59 schrieb Tavmjong Bah:
The interline spacing is given by the 'line-height' property. Line height is the distance from one baseline to the next baseline. The Inkscape GUI currently allows setting this value only based on a percentage of the 'font-size'.
That is fine, however, the Inkscape GUI doesn't mention line height but line spacing. So it's actually off by 1. The look of the default "1" setting should be achieved by setting the GUI value to "0". Either that, or the tooltip should be changed to mention line height instead of spacing.
I've changed this to "Spacing between baselines". That should be a bit clearer.
So, besides the wrong tooltip that caused much of my confusion there is also the status bar which shows the font name and size of selected objects. However, it
- uses the default display unit and not the font unit and
- doesn't take the document's view box scaling (as described by you
above) into account.
Attached you will find a patch to fix both. I am not sure if it's the right way to do it, it feels as if I mixed old C and new C++ API, but I couldn't find a pure C++ way to handle it.
I've applied the patch. Thanks!
With a non-uniform scaling, the font size reported using the patch is kind of meaningless but that is how the font size is being reported in the Text tool tool bar.
Tav
On a slightly related note, there is code in the EMF/WMF sections that snaps font sizes to the nearest .01 of a point. That and a few other similar actions were required to maintain numerical stability on import/export of these file types where drawing size is set in some number of pixels, typically on the order of thousands to tens of thousands. That limited precision would, without these optimizations, result in rounding errors causing these values to wander. With the optimizations "round trip" (open, change nothing, save with same name) results in exactly the same file, to the bit at the binary level. This made testing about 1000X easier because the numerical noise wasn't swamping out differences caused by code changes or bugs.
I don't know if other parts of Inkscape have similar code, but it is hard to imagine that similar numerical stability issues do not arise somewhere within the SVG context as well.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
participants (7)
-
Eduard Braun -
Ivan Louette -
Jabier Arraiza -
LucaDC -
mathog -
Tavmjong Bah -
Tobias Ellinghaus