font sizes specified in pixels instead of points

[Paul d'Aoust]

I've been using Inkscape for work as my only vector editor for the past
year or so, and while it's extremely capable, there is one coding choice
which I find completely bewildering: Why is font size specified in pixels
instead of points? This seems to be used in both listboxes and the actual
raw SVG. For the longest time I could not figure out why my text always
looked so small. I don't think pixels are a useful measurement for text, as
points are the de facto standard.

Using inkscape 0.44.1 autopackage.org build on Ubuntu Linux 6.06.

[Bryce Harrington (bryce)]

Originator: NO

Good question - I don't know for sure, but it's always been this way.
Perhaps someone could provide an explanation of why this is, and/or what
should be done about it?

[Johan Engelen (johanengelen)]

Originator: NO

bump

[Pierre-Luc Auclair (p-lucauclair)]

We really need a way to use either of the two. At least change the code to allow XML editing.

[Tom Davidson (tjd-mit)]

Marked a couple dupes of this bug, see left column. There is some good discussion at those bugs, but this one seemed to be the most to-the-point. Here's a quick recap:

At bug 168344, Spele03 wrote:
The font sizes in Inkscape are not "pt" but "px"! Go to the source of your
svg file and change font-size from "11px" to "11pt" and look what happens
when opening the file in Inkscape again: font size is 13.75 (px) now

90 px/in = 1.25 px/pt
72 px/in = 1.00 px/pt

To which Gez replied:
That is so wrong. Points is a standard unit for type. Every program uses points so using pixels (which is tied to the resolution) is imo the worst choice.

Mercury then suggested 2 options:
1. In Text tool panel add a unit combobox - "px, pt, mm, etc".
2. Somewhere in preferences add type units (like in Photoshop) - well, everybody knows what 12th font is, but no one knows what is 2mm font is.

[firebird (nikkie-childrensprogress)]

i was having the same problem, posted it on a dublicate bug thread (https://bugs.launchpad.net/inkscape/+bug/168344) and received a useful response that I'd like to share with you all:

***

prkos wrote (https://bugs.launchpad.net/inkscape/+bug/168344/comments/9)
Since Inkscape's default DPI is 90 (Inkscape's pixel is 1/90 of an inch), and the usual dpi is 72 you need a little math to get pt right.
If you need 10pt type, use 12.5 in Inkscape, so to get pt you want, use the points number, multiply with 1.25 and you get the Inkscape size.

This is equivalent to the post above that mentions editing svg source. If you don't want to calculate anything and use pt, select your text, go to Edit > XML editor (you'll get svg source for your text object), under Style attribute find where font-size is declared and change the number and unit to number and pt as the unit (for example from 10px to 10pt) and now hit Set button. As soon as you hit Set button you will see your entry in pt changed to the equivalent in px. You're done!

[Paul d'Aoust (paul)]

Correct me if I don't understand the meaning of 'wishlist', but I'm wondering if the importance of this bug should be promoted -- the ability to specify your units -- pt for it's a fairly critical need for anyone working in print.

Some parts of the world, e.g., Japan and (in limited cases) Germany, use other units, such as mm or q (0.25 mm), so it'd be useful to choose your units, rather than defaulting to the American/European points.

http://en.wikipedia.org/wiki/Typographic_unit
http://www.cl.cam.ac.uk/~mgk25/metric-typo/

[p01 (peezeroone)]

Ability to change font size units is vitally important thing for all who works with printing.
I doing my work in the inkscape, and part of this work is typography, printing and pre-press from time to time.
I waste a lot of time to fix font sizes in my projects, editing an xml by replacing all these "20px" to "16pt" manually. It's annoying quite enough.
Inkscape is too good to have so ridiculous misfeature. Thank you.

[Harris (henniss)]

Additionally, the text size field is unclear about the units used. One would assume that the unit is point, as it is so in nearly every other application. I personally found this bug when trying to figure out why my "18 point text" wasn't taking up 18 points on screen. If it is going to default to something odd, it should at least be clear about it.

[su_v (suv-lp)]

@Pdaoust - have you committed a patch or was your intention to give your report a higher priority by assigning it to a target milestone? If it is the later please undo your recent change and use 'Nominate for release' (select 0.48). AFAIU linking to a specific branch only makes sense if the branch contains a fix or an implementation for your issue. If you committed a patch please disregard this comment.

[Paul d'Aoust (paul)]

Oop, sorry. Looked around for something like 'nominate for release' and didn't see it. Just going blind in my old age :-)

[Paul d'Aoust (paul)]

Removed from branch and nominated for release. Apologies; I also got trigger-happy and marked 0.46 and 0.47, in the hopes of seeing it backported to those branches, but in retrospect that doesn't make much sense.

But yes, I just wanted to see this bug's priority raised, because it is quite a critical issue for many who work in print and web design. Perhaps not as critical as memory leaks or show-stopper bugs, but it is certainly unexpected behaviour.

[Paul d'Aoust (paul)]

*big happy sigh* Thanks so much, Alex. I'm really looking forward to seeing this bug nailed! I even tried to look at the source code myself to see what I could do, but it didn't take long to realise that I have no clue how to code in C++. I should just stick to what I know -- i.e., graphic design and PHP :-)

[ASteppke (asteppke-gmail)]

Is there any progress on this bug for the 0.48 release?

It has been reported several times in the last four years, confirmed and nominated. It is very user unfriendly (manually edit the size in the file) and differs from basically every other graphics or layout software that is out there (Adobe, Corel, Microsoft, Gimp, Scribus). Only in the tooltip the user can see that the font size in given in px instead of pt. Unfortunately this behavior is still in the latest Inkscape 0.48+devel r9712, so we can only hope that someone either offers the user a choice between px and pt or a similar change for the upcoming 0.48 release.

[Kjohrf (kjohrf)]

Looks like it did not make it into 0.48. Another vote for this being a crucial fix to Inkscape.

[Paul d'Aoust (paul)]

Nominated for 0.49. Devs, is it possible to elevate this to a higher priority? When I filed this bug, I initially marked it as 'Wishlist' because I didn't want it to be a pest, but after reflecting on everyone's opinions (and my experience since then), this is a fairly critical issue for anyone who wants to do print work on Inkscape. Designers have expectations about how big text is going to look when set at 10 pt, and when it comes back from the press looking too tiny for my grandma to read, it's a bit of a hassle.

Thanks! By the way, I'm really stoked about 0.48 -- I was just wishing the other day that there was a 'slice for Web' plugin, because it's a bit tedious to do in GIMP. Boy, was I surprised to learn that it's a new feature in 0.48!!!

[firebird (nikkie-childrensprogress)]

I second Kjohrf & Paul's latest comments re: escalating this if possible.

Thanks!

[vwanweb (vwanweb)]

This would be a great fix, the pt. measurement is to text as x/y coordinates is to svg.

Using px as a unit of measure for text just throws text into the wind when it comes to "print media". Once a user runs head first into this problem, there is no readily available information on how to convert the px units to pt.

http://www.w3.org/TR/SVG11/coords.html#Units

Hope this makes it into 0.49

Thank you for 0.48, the Inkscape developer team is awesome!!

[Dennis (maxka)]

Please let me point out the following: AFAIK, the px/user unit is a relative unit, which is negotiated when displaying the svg. But when working for some preprint etc stuff, absolute units are necessary. So you choose your e.g. 12pt font size to fit into a box of 2cm height. I think, as there is a qualitative difference between the px and all other units, this is an extra argument for implementing at least one absolute unit (where pt is the most usual one for fonts) in the GUI.

[Kjohrf (kjohrf)]

OK. I'll give $20 to whoever fixes this in 0.49 Is there a way to do that? If so, who else can give?

[eyerouge (spam-eyerouge)]

I'm a dev. from WTactics.org and we love to use Inkscape for plenty of our stuff. This issue is indeed a bug: While not a technical one and in the words true meaning, it's a human one beyond all logic. It shouldn't be on a "wishlist" - it's like lacking mouse or fill support in Inkscape and putting that on a wishlist. Sure, the program operates and can be used, but it doesn't in any way operate as expected/needed by the industry or even the average joe.

As it is now, it's even counter-productive, and that's possibly an even worse problem than a bug (which only says the code is broke, not the functionality of it or the program in general).

[Guillermo Espertino (Gez) (gespertino-gmail)]

Inkscape uses a resolution of 90dpi for the "real-size"
representation. So, if you create a 90x90px square it will be 1x1
inches in "real" units.
A typographic point is 1/72 of an inch, which is equal to a resolution
of 72 dpi.
90/72=1.25. So 1.25 is the factor you can use to translate between
inkscape pixels and real-world typographic points.

I guess it's pretty trivial (and probably a horrible hack) to add a
unit selector in the text dialog to choose between points and pixels
using just that factor. Internally it would simply multiply or divide
the desired size by 1.25.
It doesn't sound like an elegant solution to solve the problem, even
for my non-programmer brain. But at least it would be a temporary fix
for an old bug that people who work in print production have been
asking for years.

[Guillermo Espertino (Gez) (gespertino-gmail)]

As was stated above by Tom Davidson, there's a couple of ways to convert between inkscape pixels and points. And both are tedious :-p
You can manually change the size of every type object using the XML editor, or use a factor of 1.25 to convert the desired point size into pixels.

Inkscape uses a resolution of 90dpi for the "real-size" representation. So, if you create a 90x90px square it will be 1x1 inches in "real" units.
A typographic point is 1/72 of an inch, which is equal to a resolution of 72 dpi.
90/72=1.25. So 1.25 is the factor you can use to translate between inkscape pixels and real-world typographic points.

I guess it would be pretty trivial (and probably a horrible hack) to add a unit selector in the text dialog to choose between points and pixels using just that factor. Internally it would simply multiply or divide the desired size by 1.25.
It doesn't sound like an elegant solution to solve the problem, even for my non-programmer brain. But at least it would be a temporary fix for an old bug that people who work in print production have been asking for years.
IMHO, after four years since the original report and millions of multiplications and divisions by 1.25, even the cheapest solution looks good :-)

[frizzle21 (frederik-nnaji)]

anybody so far?
Inkscape is a vital tool for making Elements of the Graphical User Interface of Free Software.
It would be nice if an Inkscape dev could say something here, a statement at least..

[Carnë Draug (carandraug)]

This bug is still present on inkscape version 0.48

In my case made a template for the department, half of the people were using Inkscape (like me) while the other half used Illustrator. Big big mess in the end because of such a small thing.

Please fix it. Thanks

[phiscribe (dcbevins)]

Points and Pica's are bread and butter.

Pass the butter.

[Paul d'Aoust (paul)]

Amen! And a slice of bread too.

A few more reflections: After using Inkscape for mocking up a lot of website designs in the past year, I can see the benefit of being able to choose your text size units through a listbox -- perhaps at document-level, through Document Properties, although maybe to be consistent with the object scaling and moving toolbar, it should be in the text formatting toolbar instead.

Here's my web use case: on the web, pixels are absolute measurements in a way that they aren't in print. It's quite handy to set font size to 16px in my mockup, because that's most likely what I'll be doing in my CSS template as well. (Still sitting on the fence with regard to fluid-vs-fixed text sizes; zooming on all modern browsers is vastly improved.)

So I can see two very different use cases, one which requires points, and one which requires pixels. Therefore, I think it should be configurable per-file, with the default set to points.

[John Smith (john-smithi)]

Here is a patch that allows the user to set their preferred font size unit in the User preferences (Tools->Text->Text size unit) from px, pt, pc, mm, cm and in.
The text toolbar and text dialog will then show the font sizes in the users preferred unit with the tooltip showing the unit.
When text is modified or size changed, the font-size is converted from the units in the file to the users preferred units.
letter-spacing and word-spacing remain in pixels.
Internally pixels are still used for all calculations, only the file output and UI are shown the size units.

Please test if you can. Any ideas for changes ?

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "168164.v1.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[ScislaC (scislac)]

Tested.

Issue: If unit is changed to Point for example, tooltip on numeric field correctly says pt... but the tooltip for "arrow button" next to it says px.

Suggestion: I would actually vote to make points the default unit (it's what people are accustomed to in pretty much all other software they use).

Also, you did mention the document still stores as px... is there a way to add support for the "em" unit type as well since it's very web oriented (and incredibly useful)? (which would mean writing that it's em as opposed to px to the document)

[John Smith (john-smithi)]

Patch with these improvements:

* Fixed arrow tooltip
* Points is the default font unit. Do we also assume svg like "font-size;10" is also 10pt ? Currently it is assumed 10px.
* Changed the default drop-down list of font sizes to be relative to the preferred unit
* Added em unit preference.

Some observations related to "em" :
1. Inkscape uses 12px as the "default" font size. So if you have a file with "1em" font size, it is rendered as a 12px font.
2. Chrome and Firefox seem to use 12pt (16px) as the "default" font size.
3. The "Set as default" (in Text dialog) does not change the above 12px default. This means users cannot create a "relative" layout using "em" sizes, then resize it by setting the "default font size"
4. "Set as default" is currently disabled for "em" unit - due to bug #1036010

[ScislaC (scislac)]

Super exciting stuff!

As for the issue of Inkscape assuming font sizes, I think we need to assume it's px unless the font size explicitly includes a unit type.

Issue 1: When using "em", the preview size in the Text & Font dialog looks like it's still using px to calculate it. (probably related to your number 3)

Issue 2: If you are working with text and have the cursor in the toolbar's "Font size" box, if you change the unit type in preferences, the size/unit is not updated in the UI until changing or un/re-selecting text objects. (this is minor, but could confuse users)

Issue 3: One-way sync issue with T&F dialog. If you change the font size in the text toolbar it does not update in the dialog (changing the font face does, that's why I bring it up).

Issue 4: I seem to have hit an issue with em where I set the size (unit type em) to something, but when I change the font face it resets the size to 1.

[John Smith (john-smithi)]

@ScislaC, thanks for testing ...

> Issue 1:
Should be fixed in this patch.

>> Issue 3: One-way sync issue with T&F dialog. If you change the font size in the text toolbar it does not update in the dialog (changing the font face does, that's why I bring it up).
I couldn't reproduce this. Everything seems consistent between the font face and font size toolbar controls
* Changing values then tabbing out of both the font face and font size has no effect.
* Changing values then hitting Enter of both the font face and font size seem to take effect in the dialog
* Selecting from the dropdown menus also both seem to take effect in the dialog
Can you provide steps to reproduce ?

> Issue 4: I seem to have hit an issue with em where I set the size (unit type em) to something, but when I change the font face it resets the size to 1.
I couldn't reproduce this. Is this in the dialog or toolbar ?
Is it when editing existing text or new text, maybe for new text your "Set as default" size translates to 1em ?

[ScislaC (scislac)]

re: Issue 3: I am no longer seeing this issue... if I hit it again I will try to find steps to reproduce.

re: Issue 4: It's in the toolbar. In my preferences file, my default string is `style="fill:black;fill-opacity:1;stroke:none;font-family:sans-serif;font-style:normal;font-weight:normal;font-size:40px;line-height:125%;letter-spacing:0px;word-spacing:0px"`.

I can still reproduce with the new patch. Text starts off at Face: sans-serif, Size: 3.3333333333333335. I change the face and bam, size changes to 1. I change the size to 4 or 5 for example, change the face and the size changes back to 1 again.

[John Smith (john-smithi)]

OK I can reproduce Issue 4 now.
It happens when the font size is stored as em in the doc and its due to bug #1036010.
If you check the text in the XML Editor, the font-size:3.33333em will change to font-size:m; when changing font faces.
Basically a std library function is interpreting this 3.3em value as scientific "e" notation like 1.2e03 and fails.

[John Smith (john-smithi)]

Fix for bug #1036010 is now committed.
Let me know if there are any other issues, otherwise lets look to close this.

[ScislaC (scislac)]

I say commit it... I've randomly hit issues in a few sessions randomly with the UI becoming unresponsive in the text tool, but I can't reproduce or narrow down... it could be libs in ubuntu quantal or an actual issue which would benefit from wider testing on more platforms.

[John Smith (john-smithi)]

Inkscape welcome to the world on text points !
Commited to trunk as r11608.

Points is now the default unit for fonts.
Can select other units from Preferences->Tools->Text

[su_v (suv-lp)]

> Inkscape welcome to the world on text points !

A. Hard-coding the units (r11608) in the style attribute of text objects potentially does cause trouble if the SVG file is rendered by other viewers (e.g. web browsers). Text with units other than 'px' apparently may scale differently than the rest of the objects in the same drawing.

Attached sample SVG file contains 5 basic text objects with different units for font size (file is based on the default template, no transforms or viewBox atrtibutes involved, all texts use explicitly set font family 'DejaVu Sans'):
- On top are the text objects with a black fill.
- Stacked beneath is a copy of the text converted to path in Inkscape, with a red fill.
- Stacked at the bottom is a rectangle with the dimensions of the bounding box of the text as rendered in Inkscape.
Each text object (and its outlined copy as well as the bounding box rectangle) was created with a different preference setting for the font size unit:
1) In Inkscape, all text objects are rendered in the same size (even though the units differ).
2) In tested web browsers (Firefox, Chromium, Opera, Safari) and in Squiggle (Batik 1.7) on OS X 10.7.4, the text objects except the one with 'px' font size are rendered in different sizes and no longer match the outlined copy (group of paths) below nor the bounding box rectangle.

B. Hard-coding the units (r11608) in the style attribute may also cause trouble when using a viewBox attribute for the top-level <svg> node (recommended way in SVG to define real units/dimensions of the drawing content), which requires that everything in the actual drawing content is based on SVG user units (px) only.

An alternative solution would be to use the font size units only for the GUI (as it is handled elsewhere in Inkscape when a different unit is chosen), so that the SVG content itself does not mix different units.

[ScislaC (scislac)]

~suv: complimentary preference to write hardcoded units, just defaulted to off?

[su_v (suv-lp)]

ScislaC wrote:
> ~suv: complimentary preference to write hardcoded units, just defaulted to off?

I can't claim to be an SVG expert myself, and do hope that others with more insight and experience with SVG will chime in: the issue with units (SVG user units 'px' vs real (absolute) units) and the conflicts resulting due to Inkscape's current implementation (hardcoded internal resolution 90dpi along with defining document sizes without viewBox attribute) if users demand that "real" (absolute) units are to be used (which will render the same everywhere) has been discussed multiple times on the mailing lists before. Here are some links to earlier discussions (I can provide more, if needed):

Re: Units within SVG (2005-06-06)
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/9587/focus=9662>
<http://article.gmane.org/gmane.comp.graphics.inkscape.devel/9667>

Re: Font size (2005-06-06)
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/9587/focus=9666>
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/9587/focus=9668>

Re: GSoC / SVG compliance / font size (2011-03 / 2011-04)
<http://article.gmane.org/gmane.comp.graphics.inkscape.devel/36249>
<http://article.gmane.org/gmane.comp.graphics.inkscape.devel/36258>

Considering that Inkscape chose SVG as native file format, aims for better (aka 100%) compliance with the SVG spec, and is used for various tasks which have different (maybe even conflicting) demands with regard to scalability and absolute units:
If the feature stays in (allow different units for font sizes), it might make sense to make it optional, and default to using the units for the GUI only (and make that the default).

If solved this way - optional, default to GUI units only - maybe the unit selection ought to be moved to the text tool controls bar, like with all other spinboxes which allow different units for input while internally the values stored in the SVG source are converted to SVG user units (px) based on Inkscape's internal resolution (90dpi)?

[ScislaC (scislac)]

John: Any thoughts on this preference? It allows things to work "as expected" and allows power users to hit grand slams (when they choose)...

[su_v (suv-lp)]

> (…) and allows power users to hit grand slams (when they choose)...

What exactly is the benefit of hardcoding (and thus mixing) relative and (seemingly) absolute units in the same document?

[ScislaC (scislac)]

Less about benefits of mixing units, more about allowing writing to specification. I'm thinking more of web folk that will use "em" when we better support external CSS and such.

[John Smith (john-smithi)]

With this change it has become "optional", users can finally choose their preferred SVG units with the default as "industry" standard points for text. This is really the opposite of the previous situation of px only "hard coding".

> it might make sense to make it optional, and default to using the units for the GUI only
If really needed, I am ok to add a Preference to "hard code px output" - however there should be a strong case for this. Should we encourage users to not use these standard SVG units because some "other" programs don't render those units correctly ?

[su_v (suv-lp)]

> Should we encourage users to not use these standard SVG units
> because some "other" programs don't render those units correctly

Some "other" SVG renderers (i.e. all tested web browsers as well as Inkscape's reference SVG implementation batik) being incorrect is not the underlying issue AFAIU: Inkscape neglects to define a viewBox for the chosen page size and simply relies on other SVG renderers to also use 90dpi internally - the SVG 1.1 specification however does not enforce 90dpi (only recommend): SVG renderers are free to define the size of the reference pixel (web browsers commonly use 96 dpi, Scribus for example uses 72dpi) - without being non-compliant to the SVG 1.1. specification.

Anyway - I'll bow out of this discussion (I probably shouldn't have commented here at all, sorry for the distraction it caused).

[Jaspervdg (jaspervdg)]

This isn't entirely correct: " which requires that everything in the actual drawing content is based on SVG user units (px) only.", but ~suv is correct that the problem lies with the fact that Inkscape simply assumes 90dpi without fixing a viewBox and width/height. I also ran into this recently when converting from Inkscape to Corel Draw and this is an issue that really needs to be sorted out.

In other words: as far as I can tell it's not the fault of the other programs, we're simply outputting "undefined" SVG (always). As a quick fix it would probably be best to indeed output all (font) sizes as px, to ensure the least amount of "surprise". Once we fix Inkscape's horror of a unit system we can then reenable outputting sizes in other units.

As for the "em" unit, I would advise against making it available as a unit for setting the font size, as it is defined in terms of the current font-size. (Technically it is probably okay, but you then depend on inheritance of the font-size and/or the default font size of the program, which probably is not what 99% of the users want/expect.)

[David Mathog (mathog)]

Font size in the GUI should be displayed in whichever units the user wants, with the default being points and not pixels, as that is what 99% of all drawing programs use. However, there is no reason that the internal font size cannot remain in px. It only takes a tiny bit of GUI related code to convert from pt to px (or em to px), and that will not affect any other part of the program. That should resolve the (minor) usage issue without introducing any new issues. (My current solution is to do it outside the program - I have a conversion table of points<->pixels on a sheet of paper. Not very elegant, the program should do this simple conversion.)

Regarding the lack of a defined SVG viewBox, that is a separate issue and should be in its own thread. Inkscape should not let such things default to "whatever the reading program wants", as, in my experience, it is inevitable that some program will use an incompatible default. (Example: EMF import of lines with zero width - Inkscape has invisible lines, but some other programs show lines with the minimum visible width.)

[Guillermo Espertino (Gez) (gespertino-gmail)]

I love having pt as units because my work is mostly for print, and it was a real pain to calculate the type size from pixels for every text object, every time.
However I found that when I add a viewBox to documents stored with current trunk with pt as units, the size of SVG text is wrong when viewed in a browser (I tried with Iceweasel, Chromium, Gnome Web and Midori), just as ~suv pointed out.
Eye of Gnome, the image viewer, is also affected by this combination of viewBox and pt units for type.
I've started to use viewBox because inkscape SVGs are always imported with the wrong size in other programs like Scribus (and Corel, and Illustrator), which assume a resolution of 72 dpi instead of 90.

Setting a viewBox for having a real world units reference seems as important as having type in real world units to me, so this solution is incompatible.
I wonder why the units have to be "hardcoded" in the document. Why not just calculating the values on the fly in the UI and keep working with pixels, but with a properly viewBox set in the document?
Other programs seem to react correctly and assign the right size when the viewBox element is set and units in SVGs are pixels.

[John Smith (john-smithi)]

Further commit to trunk r11616
* Add an option to "always output in px" (default is off)
* Size of preview text in Font dialog should (better) match the canvas at 100% (previously we used px instead of pt)

So the current state is :

a) Inkscape uses px and 72dpi for all text transforms/calculations etc internally
b) Users can choose their preferred unit "for display" in the UI (default is points). These units are basically converted to and form px "on the fly" as needed.
c) Users can choose to output to file in preferred unit (b) or always px (default is users preferred unit)

Questions :
1. Should "always output in px" be default on ?
2. Would it make sense to have dpi configurable per document ?
3. Whats the best way to make viewBox more easily useable ?

[ScislaC (scislac)]

1) Yes it appears so as it's what users expect, even though the default unit people are dealing with should change to PT in the gui.

2) I think it's a power-user feature that would be appreciated by a decent size portion of our community, as long as it works everywhere and is defaulted to our old 90px (and assumed anything not defined otherwise is still treated as 90px until someone wants to deal with importing from various formats we support).

3) The easiest way is to create a simple viewbox which is locked to the "canvas" size and has basic attributes available in the document properties dialog. It's not ideal, but a solid first step. The main issue is that we need to be able to properly interpret viewboxes (also respecting more than one) before we should start writing them. After that, have an option in the View menu to toggle showing viewboxes in a special way (I assume the way we do path highlights or guides or grids or other on-canvas editing assistance), which could then allow to at least be easily moved or scaled by the select tool (and on such a move of the "canvas" viewbox, unlocks it from that canvas viewbox role).

Issue: With current trunk I can consistently reproduce an issue where if I create text (the default of "sans-serif" is used), if I still have a blinking cursor in the text box, clicking on the fontface dropdown arrow shows it for a fraction of a second and the gui is locked from there forward (I have to kill via terminal to get it to quit).

Note: I see no mention of 72dpi in your patch. Inkscape uses 90dpi as it's default... I'm assuming it was a typo (which is good in this case).

[John Smith (john-smithi)]

Committed r11621 - "always output in px" is now on by default.

>Issue: With current trunk I can consistently reproduce an issue where if I create text (the default of "sans-serif" is used), if I still have a blinking cursor in the text box, clicking on the fontface dropdown arrow shows it for a fraction of a second and the gui is locked from there forward (I have to kill via terminal to get it to quit).
Cant reproduce. I do see the dropdown show for a second, then disappear, but the UI does not lock up on Ubuntu 12.04.

> Inkscape uses 90dpi as it's default
Sorry my mistake.

[David Mathog (mathog)]

There are some rounding errors in the font size display in r11664. Open the attached example file. 18.2pt is 22.75 px in the XML editor, but 18.19999999 (plus or minus a few 9's) in the display.

The fix would be for the bit of code that is displaying the point size, wherever that is, to do this:

  font_size = round (1000.0 * font_size)/1000.0;

Or 10000. It loses a bit of precision, but are there any applications that need 1/10000th of a px font size precision?

In any case 18.199999999 -> 18.200 and would then display as 18.2.

[John Smith (john-smithi)]

Commit r11675 :
* fix the precision issue (comment #52)
* show font size to precision in user preference Input/Output->SVG Output->Numeric precision.

@David, thanks for spotting that, should be fixed now, let me know if you see any other bad cases.
BTW Fix is to use Inkscape::CSSOStringStream which takes care of rounding and truncating zeros.

[dopelover (dopelover)]

I've noticed a strange behaviour. Rounding units works in a weird way in some text areas.

1) draw flow text area
2) fill it with standard "Lorem Ipsum" (Extension>Text>Lorem Ipsum...)
3) select created text and change font size
4) observe the font size values in a input area (text toolbar or Text and Font dialog)

For example when I set font size to 26,25pt I get 25,84pt.

This issue affects inkscape r11595 on Windows XP.

[insaner (insaner)]

was not able to compile on fedora 14 with

 $ rpm -q gtkmm24
gtkmm24-2.22.0-1.fc14.i686

(14:28:35) insaner: $ rpm -q gtk2
gtk2-2.22.0-1.fc14.1.i686

it was throwing a

   CXX widgets/font-selector.o
widgets/font-selector.cpp: In function ‘void sp_font_selector_set_sizes(SPFontSelector*)’:
widgets/font-selector.cpp:352:67: error: cannot convert ‘double’ to ‘const gchar*’ for argument ‘2’ to ‘void gtk_combo_box_append_text(GtkComboBox*, const gchar*)’
make[3]: *** [widgets/font-selector.o] Error 1

so i went to that line stared for a while.. tried a few things, and this seems to have fixed it:

change line 352 in widgets/font-selector.cpp from
----------
#if GTK_CHECK_VERSION(2, 24,0)
        gtk_combo_box_text_append_text (GTK_COMBO_BOX_TEXT(fsel->size), Glib::ustring::format(size).c_str());
#else
        gtk_combo_box_append_text (GTK_COMBO_BOX(fsel->size), size);
#endif
    }
 -----------
to
 -----------

#if GTK_CHECK_VERSION(2, 24,0)
        gtk_combo_box_text_append_text (GTK_COMBO_BOX_TEXT(fsel->size), Glib::ustring::format(size).c_str());
#else
        gtk_combo_box_append_text (GTK_COMBO_BOX(fsel->size), Glib::ustring::format(size).c_str());
#endif
    }
 -----------

ie, replace "size" with "Glib::ustring::format(size).c_str()"

hope that helps

[John Smith (john-smithi)]

Thanks for finding that insaner !
Committed to trunk as r11733.

[Jasper Frumau (jfrumau)]

If I use pixels as default unit and dimensions in pixels why can't the font size be in pixels too? Why is there not an option to choose the font unit? Initially I thought I had the font in pixels which in needed for my webdesign template but when I checked the source code using the XML editor I realized it was in points and was just converted. Later on I found this thread and realized that after a long debate the font unit was made in pt. Why can't we choose to make both print people and web people like me happy? An option in the document setting perhaps would work. This way all can be displayed in pixels when need be, not just the document size or units, but also the text. And if print people want pt they could have that too.

[Paulo Coghi (paulocoghi)]

Suggestion: make the font unit selectable.

No matter if it will or will not be defined form the default document unit, the important thing is to make it modifiable.

You can even set "pt" as default and there is no problem. It's just interesting to provide a select box on page settings that allows the font unit change to/from "pt" and "px".

Everybody will be happy, both when designing for print or for web.