How to input non-ASCII characters in Inkscape
I see variants on this question from time to time, like
How does one get special characters, like left and right quotes, in Inkscape's text?
How do I type Greek/Russian/Chinese/Tamil/... in Inkscape?
Here's the answer as best as I know. I hope people can fill in the gaps, and perhaps work on making this easier to do from Inkscape.
If you only rarely need to type the odd ‘déjà vu’ or degree sign, then the simplest way is with a gui character selection program like gucharmap (Accessories>Character Map in the Gnome menu, or Text>Unicode character map in the Debian menu system).
gucharmap wishlist item (which I haven't yet reported): It might be nice if gucharmap made it a bit easier to find commonly-sought characters (introducing hierarchy into the long list of categories, or adding one or more pseudo-blocks of commonly-sought characters that might span more than one of the named blocks). (In its favour, gucharmap does have a search function that can search in character names & descriptions.)
Also, it might be nice if gucharmap were to to show any Multi-key combinations defined for the character (see below).
If you type non-ASCII characters a little more often, then you might instead use Compose/Multi-key key sequences. The file /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose lists available key sequences. Many of these sequences start with <Multi_key>. Some keyboards have a Compose key labelled as such. Some X sessions are configured to use the right `Alt' key as Compose/Multi. In my case, I use a ~/.xmodmap file that makes my print-screen key act as a compose/multi key: the ~/.xmodmap file contains a line
keycode 0x6F = Multi_key Sys_Req
and I do xmodmap "$HOME"/.xmodmap in my ~/.xsession file.
However, note that some of the key sequences of interest (e.g. Multi_key o o for degree sign, or Multi_key < " for open curly double quote and similarly the corresponding > and ' versions for closing or single quotes) are available only when using the X input method rather than gtk's default input method -- see below.
For typing extended blocks of non-Roman script, you'll want to use an input method. The only way I know of to switch between input methods in a running inkscape session is to open the Text dialog box (Ctrl-Shift-T or in the Text menu) and go to its Text tab and right-click in the text entry area: gtk should give you its standard text-entry context menu including an Input Methods submenu.
One can change gtk's default input method (usable in Inkscape's standard in-document text entry) with the GTK_IM_MODULE environment variable, e.g. export GTK_IM_MODULE=xim (X input method) or export GTK_IM_MODULE=scim (Chinese, if you have the scim package and its gtk input method on your system).
It would be nice if Inkscape offered an Input Methods submenu in its context menu for text entry. Abiword has code to do this in abi/src/af/xap/unix/xap_UnixFrameImpl.cpp:XAP_UnixFrameImpl::_runModalContextMenu, but I haven't looked into that.
Should Inkscape do anything else to make it easier to enter non-ASCII characters? Perhaps have an item in the Text menu to launch gucharmap?
Should something like this message go into a short tutorial available in the Help menu?
pjrm.
On Fri, Jun 03, 2005 at 01:03:19AM +1000, Peter Moulder wrote:
I see variants on this question from time to time, like
How does one get special characters, like left and right quotes, in Inkscape's text?
How do I type Greek/Russian/Chinese/Tamil/... in Inkscape?
Here's the answer as best as I know. I hope people can fill in the gaps, and perhaps work on making this easier to do from Inkscape.
This is great info, Peter. Since as you say, this is a commonly asked thing, it sounds like it would be wise to add this to wiki and the FAQ.
Josh, would you mind working with Peter to add this one to the FAQ? I figure the FAQ could just have a short 1-2 paragraph summary of what Peter's written, with a pointer to a tutorial or a wiki page or whatever?
Bryce
If you only rarely need to type the odd ???d??j?? vu??? or degree sign, then the simplest way is with a gui character selection program like gucharmap (Accessories>Character Map in the Gnome menu, or Text>Unicode character map in the Debian menu system).
gucharmap wishlist item (which I haven't yet reported): It might be nice if gucharmap made it a bit easier to find commonly-sought characters (introducing hierarchy into the long list of categories, or adding one or more pseudo-blocks of commonly-sought characters that might span more than one of the named blocks). (In its favour, gucharmap does have a search function that can search in character names & descriptions.)
Also, it might be nice if gucharmap were to to show any Multi-key combinations defined for the character (see below).
If you type non-ASCII characters a little more often, then you might instead use Compose/Multi-key key sequences. The file /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose lists available key sequences. Many of these sequences start with <Multi_key>. Some keyboards have a Compose key labelled as such. Some X sessions are configured to use the right `Alt' key as Compose/Multi. In my case, I use a ~/.xmodmap file that makes my print-screen key act as a compose/multi key: the ~/.xmodmap file contains a line
keycode 0x6F = Multi_key Sys_Req
and I do xmodmap "$HOME"/.xmodmap in my ~/.xsession file.
However, note that some of the key sequences of interest (e.g. Multi_key o o for degree sign, or Multi_key < " for open curly double quote and similarly the corresponding > and ' versions for closing or single quotes) are available only when using the X input method rather than gtk's default input method -- see below.
For typing extended blocks of non-Roman script, you'll want to use an input method. The only way I know of to switch between input methods in a running inkscape session is to open the Text dialog box (Ctrl-Shift-T or in the Text menu) and go to its Text tab and right-click in the text entry area: gtk should give you its standard text-entry context menu including an Input Methods submenu.
One can change gtk's default input method (usable in Inkscape's standard in-document text entry) with the GTK_IM_MODULE environment variable, e.g. export GTK_IM_MODULE=xim (X input method) or export GTK_IM_MODULE=scim (Chinese, if you have the scim package and its gtk input method on your system).
It would be nice if Inkscape offered an Input Methods submenu in its context menu for text entry. Abiword has code to do this in abi/src/af/xap/unix/xap_UnixFrameImpl.cpp:XAP_UnixFrameImpl::_runModalContextMenu, but I haven't looked into that.
Should Inkscape do anything else to make it easier to enter non-ASCII characters? Perhaps have an item in the Text menu to launch gucharmap?
Should something like this message go into a short tutorial available in the Help menu?
pjrm.
-- bbyak: swatches, rich text, gradient on canvas... JonCruz: The answer to the ultimate question of life, the universe, and everything... JonCruz: Inkscape 0.42!!!!!!!
This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 6/2/05, Peter Moulder <Peter.Moulder@...38...> wrote:
If you only rarely need to type the odd 'déjà vu' or degree sign, then the simplest way is with a gui character selection program like gucharmap (Accessories>Character Map in the Gnome menu, or Text>Unicode character map in the Debian menu system).
And if you know the Unicode codepoint, just press Ctrl+U and type it. This method deserves to be mentioned first because it requires no external programs.
If you type non-ASCII characters a little more often, then you might instead use Compose/Multi-key key sequences.
This one is Unix-only, so I don't think we should put it in a FAQ at all, given that there's plenty of other ways.
For typing extended blocks of non-Roman script, you'll want to use an input method. The only way I know of to switch between input methods in a running inkscape session is to open the Text dialog box (Ctrl-Shift-T or in the Text menu) and go to its Text tab and right-click in the text entry area: gtk should give you its standard text-entry context menu including an Input Methods submenu.
Kees, you were going to apply the patch I sent you, which made it possible to do this right on canvas, via right-click menu. What stopped you?
It would be nice if Inkscape offered an Input Methods submenu in its context menu for text entry. Abiword has code to do this in
Here's the patch for it, again, in case someone wants to apply and test it:
http://article.gmane.org/gmane.comp.graphics.inkscape.devel/2045/match=input...
Should Inkscape do anything else to make it easier to enter non-ASCII characters? Perhaps have an item in the Text menu to launch gucharmap?
We don't want menu items (other than extensions) that depend on external programs. But this can be made an extension if you think it will be more accessible that way.
On Thu, 02 Jun 2005 15:06:01 -0300, bulia byak wrote:
And if you know the Unicode codepoint, just press Ctrl+U and type it. This method deserves to be mentioned first because it requires no external programs.
Wouldn't it be better to follow ISO 14755 like GIMP and Gnome? http://www.cl.cam.ac.uk/~mgk25/volatile/ISO-14755.pdf
Regards, Helge
On Mon, Jun 06, 2005 at 04:59:52AM -0400, Helge Hielscher wrote:
On Thu, 02 Jun 2005 15:06:01 -0300, bulia byak wrote:
And if you know the Unicode codepoint, just press Ctrl+U and type it. This method deserves to be mentioned first because it requires no external programs.
Wouldn't it be better to follow ISO 14755 like GIMP and Gnome? http://www.cl.cam.ac.uk/~mgk25/volatile/ISO-14755.pdf
Thanks for bringing that to our attention.
I've now adapted Inkscape's existing unicode entry method to conform to section 5.1 of that standard, with Ctrl-U as the "beginning sequence" and <Ret> or keypad-enter as "ending sequences". I've implemented the recommended behaviour for <space> key.
Differences from gtk (as tested in gedit; gimp 2.2.6 seems the same, though I haven't tested gimp much):
Differences where Inkscape CVS has better behaviour or where Inkscape conforms more to the spec:
- gtk doesn't allow beginning the hex sequence with 0 (contrary to ISO 14755).
- gtk doesn't implement the recommended behaviour for <space>.
- gtk doesn't allow pressing backspace at the hexadecimal level. (Not required by the spec.)
Differences where gtk better implements the spec: None to my knowledge.
Other differences:
- gtk uses press of ctrl and shift as the "beginning sequence", and release of those keys as the "ending sequence", whereas inkscape uses Ctrl-U for begin as it has in the past, and GDK_Return or GDK_KP_Enter as ending sequence.
Ctrl+Shift is presumably more widespread (e.g. it is used in the examples in the spec; though the spec explicitly this as merely an example rather than recommendation). OTOH, it would conflict with Inkscape's widespread use of Ctrl+Shift in shortcuts. E.g. we might want Ctrl-Shift-B to toggle bold. (Also, Ctrl+Shift is harder to implement than Ctrl-U.)
- gtk commits a character and starts the next one as soon as the user types a hex digit that would make a number greater than 0x10fffd; that digit becomes the start of the next hex sequence, unless the digit is zero, in which case `)' is inserted (shift-0). Non-hex-digits are ignored: 123z4 is the same as 1234.
Inkscape CVS commits a character and starts the next one as soon as the ninth hex digit is typed. (The ninth hex digit is then considered the first digit in the next character, similar to gtk.)
If a non-hex-digit is typed, then previous Inkscape behaviour was that unicode entry is cancelled without inserting anything (not even the non-hex-digit). After thinking about this overnight, I decided to adopt gtk behaviour, but retaining <Esc> and Ctrl-U as ways to cancel. (Gtk has no cancel key to my knowledge, though of course one can backspace over the wrongly-inserted character for much the same effect.) Apart from greater consistency with gtk, this is more forgiving on poor motor skills or other causes of mistyping. OTOH, Inkscape's previous behaviour is better for if people didn't mean to initiate unicode entry.
I don't know how gtk behaves if the user is using a non-Latin keyboard. The ISO spec recommends that the first 6 chars of the non-Latin alphabet be usable as hex digits when latin is not available. Inkscape instead forces a `group 0' interpretation of the keystroke, which we hope to correspond to the Latin alphabet. (We do the same thing for shortcuts: our shortcuts are the same in all locales.) Can users of non-Latin keyboards comment on whether you prefer the spec's suggestion, Inkscape's implementation, or have no preference? Do the two conflict? (E.g. are Cyrillic De & Ie (Д & Е) considered the fifth & sixth letters of the Russian alphabet, and are they on the same keys as latin's 4th & 5th letters (D & E) respectively?) Can anyone point to code to implement the spec's suggestion? (I haven't checked gtk sources.)
I believe Inkscape CVS conforms to section 5.1 in all other respects.
None of the other methods in section 5 of the spec are implemented by either Inkscape or gtk to my knowledge; though in both cases one might argue that the availability of the gunichar program or similar would fulfil most of sections 5.3 and 5.4.
pjrm.
On Thu, 09 Jun 2005 11:18:59 +1000, Peter Moulder wrote:
On Mon, Jun 06, 2005 at 04:59:52AM -0400, Helge Hielscher wrote:
I've now adapted Inkscape's existing unicode entry method to conform to section 5.1 of that standard, with Ctrl-U as the "beginning sequence" and <Ret> or keypad-enter as "ending sequences". I've implemented the recommended behaviour for <space> key.
Wow. Thank you, that was fast.
Other differences:
- gtk uses press of ctrl and shift as the "beginning sequence", and release of those keys as the "ending sequence", whereas inkscape uses Ctrl-U for begin as it has in the past, and GDK_Return or GDK_KP_Enter as ending sequence. Ctrl+Shift is presumably more widespread (e.g. it is used in the examples in the spec; though the spec explicitly this as merely an example rather than recommendation). OTOH, it would conflict with Inkscape's widespread use of Ctrl+Shift in shortcuts. E.g. we might want Ctrl-Shift-B to toggle bold. (Also, Ctrl+Shift is harder to implement than Ctrl-U.)
Could you please make Ctrl-Shift an option? All applications I have tried (Mozilla, GIMP, Gedit, Abiword) use it. It would make entering unicode more consistant.
Regards, Helge Hielscher
I occurs to me that...
1.) Isn't this solution a bit too technical for a typical user? 2.) It may be great for *IX users, but what about other OS's?
So, to answer your question about whether or not further consideration of this issue is warranted, I think it is. I would kindly suggest that the requirements for Inkscape's capabilities in this regard should be...
1.) Platform independent, cross-platform compatible 2.) Completely non-technical, with no understanding of your computer's configuration.
Regards, -kwixson
Peter Moulder wrote:
I see variants on this question from time to time, like
How does one get special characters, like left and right quotes, in Inkscape's text?
How do I type Greek/Russian/Chinese/Tamil/... in Inkscape?
Here's the answer as best as I know. I hope people can fill in the gaps, and perhaps work on making this easier to do from Inkscape.
If you only rarely need to type the odd ‘déjà vu’ or degree sign, then the simplest way is with a gui character selection program like gucharmap (Accessories>Character Map in the Gnome menu, or Text>Unicode character map in the Debian menu system).
gucharmap wishlist item (which I haven't yet reported): It might be nice if gucharmap made it a bit easier to find commonly-sought characters (introducing hierarchy into the long list of categories, or adding one or more pseudo-blocks of commonly-sought characters that might span more than one of the named blocks). (In its favour, gucharmap does have a search function that can search in character names & descriptions.)
Also, it might be nice if gucharmap were to to show any Multi-key combinations defined for the character (see below).
If you type non-ASCII characters a little more often, then you might instead use Compose/Multi-key key sequences. The file /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose lists available key sequences. Many of these sequences start with <Multi_key>. Some keyboards have a Compose key labelled as such. Some X sessions are configured to use the right `Alt' key as Compose/Multi. In my case, I use a ~/.xmodmap file that makes my print-screen key act as a compose/multi key: the ~/.xmodmap file contains a line
keycode 0x6F = Multi_key Sys_Req
and I do xmodmap "$HOME"/.xmodmap in my ~/.xsession file.
However, note that some of the key sequences of interest (e.g. Multi_key o o for degree sign, or Multi_key < " for open curly double quote and similarly the corresponding > and ' versions for closing or single quotes) are available only when using the X input method rather than gtk's default input method -- see below.
For typing extended blocks of non-Roman script, you'll want to use an input method. The only way I know of to switch between input methods in a running inkscape session is to open the Text dialog box (Ctrl-Shift-T or in the Text menu) and go to its Text tab and right-click in the text entry area: gtk should give you its standard text-entry context menu including an Input Methods submenu.
One can change gtk's default input method (usable in Inkscape's standard in-document text entry) with the GTK_IM_MODULE environment variable, e.g. export GTK_IM_MODULE=xim (X input method) or export GTK_IM_MODULE=scim (Chinese, if you have the scim package and its gtk input method on your system).
It would be nice if Inkscape offered an Input Methods submenu in its context menu for text entry. Abiword has code to do this in abi/src/af/xap/unix/xap_UnixFrameImpl.cpp:XAP_UnixFrameImpl::_runModalContextMenu, but I haven't looked into that.
Should Inkscape do anything else to make it easier to enter non-ASCII characters? Perhaps have an item in the Text menu to launch gucharmap?
Should something like this message go into a short tutorial available in the Help menu?
pjrm.
On 6/2/05, Kevin Wixson <kevin@...738...> wrote:
1.) Platform independent, cross-platform compatible 2.) Completely non-technical, with no understanding of your computer's configuration.
Yes, this is Ctrl+U. The rest is optional.
On 6/2/05, Peter Moulder <Peter.Moulder@...38...> wrote:
I see variants on this question from time to time, like
How does one get special characters, like left and right quotes, in Inkscape's text?
I know that Inkscape differs from InDesign _a lot_, but the thing I like about ID is that its text frame's pop-up menu has a couple of submenus for inserting special characters like (C), (R), and different types of quotation marks. Scribus (1.3cvs) has such submenus now as well, but in main application's menu Insert.
Would it be a good idea to add such a functionality to Inkscape?
Alexandre
On Sunday 05 Jun 2005 16:22, Alexandre Prokoudine wrote:
I know that Inkscape differs from InDesign _a lot_, but the thing I like about ID is that its text frame's pop-up menu has a couple of submenus for inserting special characters like (C), (R), and different types of quotation marks. Scribus (1.3cvs) has such submenus now as well, but in main application's menu Insert.
Would it be a good idea to add such a functionality to Inkscape?
I don't speak for anyone on the Inkscape team, but personally, I'd rather not see this in Inkscape. Your OS almost certainly already provides that feature. And, since international unicode character sets consist of tens of thousands of characters, any attempt by inkscape to reproduce that functionality would be very limited by comparison.
Have a look around your OS for a "character selection" utility, or something similar. Also, if you're using X windows, lookup the details for xmodmap, which will let you map copyright to AltGr-c or whatever key you want.
I think you're asking a lot of users, just to avoid doing something that other programs offer. If it's so problematic, why do other programs do it?
Digital Unleashed wrote:
On Sunday 05 Jun 2005 16:22, Alexandre Prokoudine wrote:
I know that Inkscape differs from InDesign _a lot_, but the thing I like about ID is that its text frame's pop-up menu has a couple of submenus for inserting special characters like (C), (R), and different types of quotation marks. Scribus (1.3cvs) has such submenus now as well, but in main application's menu Insert.
Would it be a good idea to add such a functionality to Inkscape?
I don't speak for anyone on the Inkscape team, but personally, I'd rather not see this in Inkscape. Your OS almost certainly already provides that feature. And, since international unicode character sets consist of tens of thousands of characters, any attempt by inkscape to reproduce that functionality would be very limited by comparison.
Have a look around your OS for a "character selection" utility, or something similar. Also, if you're using X windows, lookup the details for xmodmap, which will let you map copyright to AltGr-c or whatever key you want.
On 6/5/05, Kevin Wixson <kevin@...738...> wrote:
I think you're asking a lot of users, just to avoid doing something that other programs offer. If it's so problematic, why do other programs do it?
Because text doesn't consist of letters and punctuation marks only. And you surely want other often used special characters to be easy accessible. E.g. following russian typography traditions you need two types of quotation marks for a text in two languages like Russian and English, because Russian quotation marks are not the same as in American English. Using a pop-up menu or even a hotkey is _a lot_ easier than going to gucharmap or whatever or even using clipboard. This is the matter of experience, no kidding, no offence :)
Alexandre
Alexandre: I'm afraid you missed my point, but thank you for articulating the point further. I am actually in favor of some sort of in-program solution for adding these characters and was sincerely asking, "If other programs do it, why shouldn't Inkscape?" I think it should.
That said, it may not be a priority issue, and other features and enhancements may need to come first. I would just like it if someone acknowledged it as a feature Inkscape could and should have at some point down the road.
Alexandre Prokoudine wrote:
On 6/5/05, Kevin Wixson <kevin@...738...> wrote:
I think you're asking a lot of users, just to avoid doing something that other programs offer. If it's so problematic, why do other programs do it?
Because text doesn't consist of letters and punctuation marks only. And you surely want other often used special characters to be easy accessible. E.g. following russian typography traditions you need two types of quotation marks for a text in two languages like Russian and English, because Russian quotation marks are not the same as in American English. Using a pop-up menu or even a hotkey is _a lot_ easier than going to gucharmap or whatever or even using clipboard. This is the matter of experience, no kidding, no offence :)
Alexandre
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 6/5/05, Kevin Wixson <kevin@...738...> wrote:
Alexandre: I'm afraid you missed my point,
Not really. I've answered rather to Digital Unleashed, but couldn't stop myself from using your letter as a starting point :)
That said, it may not be a priority issue, and other features and enhancements may need to come first. I would just like it if someone acknowledged it as a feature Inkscape could and should have at some point down the road.
+1
I personally think that having a consistent text toolbar is much more important in usability aspect. But I'm just a user and translator. Don't count on me when it comes to actually coding :)
Alexandre
Digital Unleashed wrote:
On Sunday 05 Jun 2005 16:22, Alexandre Prokoudine wrote:
Would it be a good idea to add such a functionality to Inkscape?
I don't speak for anyone on the Inkscape team, but personally, I'd rather not see this in Inkscape. Your OS almost certainly already provides that feature. And, since international unicode character sets consist of tens of thousands of characters, any attempt by inkscape to reproduce that functionality would be very limited by comparison.
I would guess, however, that most users only use 10 to 15 odd characters with great regularity. So a configurable quickpick list might be a nice feature. Users who get more indepth than that will certainly know how to use the OS's character selector tool.
Aaron Spike
On Sunday 05 June 2005 18:14, Digital Unleashed wrote:
On Sunday 05 Jun 2005 16:22, Alexandre Prokoudine wrote:
I know that Inkscape differs from InDesign _a lot_, but the thing I like about ID is that its text frame's pop-up menu has a couple of submenus for inserting special characters like (C), (R), and different types of quotation marks. Scribus (1.3cvs) has such submenus now as well, but in main application's menu Insert.
Would it be a good idea to add such a functionality to Inkscape?
I don't speak for anyone on the Inkscape team, but personally, I'd rather not see this in Inkscape. Your OS almost certainly already provides that feature. And, since international unicode character sets consist of tens of thousands of characters, any attempt by inkscape to reproduce that functionality would be very limited by comparison.
Have a look around your OS for a "character selection" utility, or something similar. Also, if you're using X windows, lookup the details for xmodmap, which will let you map copyright to AltGr-c or whatever key you want.
Simply, your OS will lie to you.
Yes. Many will do auto glyph substitution which you certainly DO NOT want in DTP (they will often show more glyphs than are available within a certain font file). Many are too complicated and the interfaces are inconsistent with the application, especially across platform.
For these reasons, Scribus has its own Insert Glyph dialog which Scribus itself generates from freetype information (as we do not rely on anything other than freetype and the font files themselves).
DTP programs typically ALSO have a standard set of (C), (R), TM, spacing, quoting etc glyphs on a menu because its a handy way to get at these characters without searching through an Insert Glyph dialog that can contain thousands of characters.
The amount of requests for this we have for what we have now in Scribus has been quite high over time, hence its now in 1.3.0cvs.
Also, The ISO 14755 *suggests* Control-Shift for insertion of unicode chars. I know that GTK2 supports this, but I havent tested it with Inkscape yet.
While Inkscape isnt a DTP program as such, it can be used for that, and it is certainly used in conjunction with apps like Scribus.
Craig Scribus Team
On Sunday 05 Jun 2005 22:13, Craig Bradney wrote:
Simply, your OS will lie to you.
Yes. Many will do auto glyph substitution which you certainly DO NOT want in DTP (they will often show more glyphs than are available within a certain font file). Many are too complicated and the interfaces are inconsistent with the application, especially across platform.
Ahh, font aliases? That's good point, yes.
On complexity of the character selection tools, though, I think that would be a matter best solved by adding a basic mode to the tools, rather than trying to re-invent the wheel.
I don't think it's such an issue anyway: if people are modifying nodes on a bezier curve and managing layers, launching a program to copy and paste a character should not be too difficult. It seems to me that it would be more difficult to suggest a different way of doing it from what they may be used to in other applications. After all, if they need those characters in Inkscape, they probably need them on their emails or their word processor or something too.
Operating systems already supply this functionality, so I think it's silly to pretend we know the operating system better than the people who develop them. That sort of thing used to happen a lot back in the early nineties, with people re-inventing GUIs over and over again. Mostly, it was a mistake. The only time we see that happen often now is in GUI skins. What you get is something that looks cool and might sell more products (if that's a goal), but fits in badly with the rest of the UI experience, and damages overall workflow.
I didn't know there was an ISO suggestion for keystrokes. Seems like a good thing to support.
On Sunday 05 June 2005 23:47, Lee Braiden wrote:
On Sunday 05 Jun 2005 22:13, Craig Bradney wrote:
Simply, your OS will lie to you.
Yes. Many will do auto glyph substitution which you certainly DO NOT want in DTP (they will often show more glyphs than are available within a certain font file). Many are too complicated and the interfaces are inconsistent with the application, especially across platform.
Ahh, font aliases? That's good point, yes.
On complexity of the character selection tools, though, I think that would be a matter best solved by adding a basic mode to the tools, rather than trying to re-invent the wheel.
At least for Gnome, a request should be put in to have an option to stop the glyph substitution/font aliasing. Its completely inappropriate for DTP work, and I'd also say for Inkscape's pure vector use too (EPS and PDF export wont like substituted glyphs in this sense). However, for those of us who don't use Gnome, or arent on Linux, this doesnt help.
Craig
I am using Win2000. Inkscape 27th May 05.
It is a while since I've done much with Inkscape and I have probably set something up incorrectly. But I don't know what.
I set up to print with Arial at font size 100. Then I print and the letters are 20mm high.
I set up CorelDraw and do the same. The letters are 25mm high. Same with Word.
Ie Inkscape appears to be printing out at 4/5 of the correct size. This seems so basic that I feel I must be doing something wrong or have a setting wrong. Any suggestions or comments?
Erik
On Jun 5, 2005, at 4:18 PM, Erik wrote:
Ie Inkscape appears to be printing out at 4/5 of the correct size. This seems so basic that I feel I must be doing something wrong or have a setting wrong. Any suggestions or comments?
Inkscape is an SVG app, and does things "SVG-style".
One of the interesting things is that SVG follows CSS size rules in that things are based on display units that may change. By default things are set to use an assumed 90 DPI value. The difference between 72 DPI and 90 DPI gives you the 4/5ths factor you're seeing.
In general, try multiplying or dividing by either 80 or 1.25.
This is a bit of a tricky area, as I believe that once we change things to follow the specs even closer, it would entail getting the DPI from the runtime display environment (though if not done properly, things would quickly devolve into chaos)
On Monday 06 June 2005 02:06, Jon A. Cruz wrote:
On Jun 5, 2005, at 4:18 PM, Erik wrote:
Ie Inkscape appears to be printing out at 4/5 of the correct size. This seems so basic that I feel I must be doing something wrong or have a setting wrong. Any suggestions or comments?
Inkscape is an SVG app, and does things "SVG-style".
One of the interesting things is that SVG follows CSS size rules in that things are based on display units that may change. By default things are set to use an assumed 90 DPI value. The difference between 72 DPI and 90 DPI gives you the 4/5ths factor you're seeing.
In general, try multiplying or dividing by either 80 or 1.25.
This is a bit of a tricky area, as I believe that once we change things to follow the specs even closer, it would entail getting the DPI from the runtime display environment (though if not done properly, things would quickly devolve into chaos)
Which may or may not be correct depending on what the X server is thinking at the time. If this is not correct, then you need a ruler to set up a scaling % like in Scribus so it can be display setting independent.
Craig
Jon wrote: Inkscape is an SVG app, and does things "SVG-style".
One of the interesting things is that SVG follows CSS size rules in that things are based on display units that may change. By default things are set to use an assumed 90 DPI value. The difference between 72 DPI and 90 DPI gives you the 4/5ths factor you're seeing.
In general, try multiplying or dividing by either 80 or 1.25.
This is a bit of a tricky area, as I believe that once we change things to follow the specs even closer, it would entail getting the DPI from the runtime display environment (though if not done properly, things would quickly devolve into chaos) I would not use the word interesting and I'm certainly not going to mult or divide by a factor on all the different font sizes I use. I am making geological maps where there are lots of small titles, names, comments etc scattered over the map.
Can I change this default 90DPI to 72DPI display units anywhere? And if I can, is there anything else that that will screw up as a result? Line width etc.
Thanks, Erik
On 6/5/05, Erik <kaver@...68...> wrote:
Can I change this default 90DPI to 72DPI display units anywhere? And if I can, is there anything else that that will screw up as a result? Line width etc.
You don't need to know anything about DPIs. Just use one unit for everything. The default unit in Inkscape is px; you can change that to use pt instead. The only problem is that the font size selector does not currently allow you to choose units, but we'll fix that eventually.
Bulia wrote:
You don't need to know anything about DPIs. Just use one unit for everything. The default unit in Inkscape is px; you can change that to use pt instead. The only problem is that the font size selector does not currently allow you to choose units, but we'll fix that eventually.
OK. Where do I change it? I can see units choice at
File/document preferences/page/default units File/document preferences/page/custom canvas File/document preferences/grid/snap units and File/document preferences/guides
Do I change them all? Or which? or a different one alltogether? Erik
On 6/5/05, Erik <kaver@...68...> wrote:
OK. Where do I change it? I can see units choice at
File/document preferences/page/default units
This one, of course.
On 6/5/05, Erik <kaver@...68...> wrote:
OK. Where do I change it? I can see units choice at
File/document preferences/page/default units
This one, of course.
OK. So it changes the second to pt as well and leaves the others (grid and guides)at px. Can I make that change sticky?
AAAARRRGGHH. Now I cannot change font size at all. Erik
On 6/5/05, Erik <kaver@...68...> wrote:
OK. So it changes the second to pt as well and leaves the others (grid and guides)at px. Can I make that change sticky?
It's saved with the document.
AAAARRRGGHH. Now I cannot change font size at all.
What do you mean?
----- Original Message ----- From: "bulia byak" <buliabyak@...400...> To: "Erik" <kaver@...68...> Cc: "Jon A. Cruz" <jon@...18...>; inkscape-devel@lists.sourceforge.net Sent: Monday, June 06, 2005 1:05 PM Subject: Re: [Inkscape-devel] Font size
On 6/5/05, Erik <kaver@...68...> wrote:
OK. So it changes the second to pt as well and leaves the others (grid
and
guides)at px. Can I make that change sticky?
It's saved with the document.
AAAARRRGGHH. Now I cannot change font size at all.
What do you mean?
It means "AAAARRRGGHH. Now I cannot change font size at all." The font and text dialog was frozen. However that is history. I have scrubbed Inkscape and reinstalled. With a clean install changing to pt as suggested seems to make no difference to font size output.
Using a factor of 1.25 is workable as long as I remember.
Erik
On 6/6/05, Erik <kaver@...68...> wrote:
and reinstalled. With a clean install changing to pt as suggested seems to make no difference to font size output.
I didn't say it will change font size. I only suggested switching to pt so that everything else in the document is in the same units as fonts, so that there's a size match. However now that I check, the font size selector does not seem to match even pt sizes. It's very old part of code which no one touched to date. I'll look into it.
Quoting bulia byak <buliabyak@...400...>:
I didn't say it will change font size. I only suggested switching to pt so that everything else in the document is in the same units as fonts, so that there's a size match.
That won't work for paths. You have to use px (and get fonts in px somehow).
-mental
On 6/6/05, mental@...3... <mental@...3...> wrote:
Quoting bulia byak <buliabyak@...400...>:
I didn't say it will change font size. I only suggested switching to pt so that everything else in the document is in the same units as fonts, so that there's a size match.
That won't work for paths. You have to use px (and get fonts in px somehow).
It may not work in other renderers, see above. But if you stay within Inkscape, pt are as good as px, from UI viewpoint (i.e. if you don't look into how the paths are stored in the source).
On Sun, 2005-06-05 at 21:11, bulia byak wrote:
You don't need to know anything about DPIs. Just use one unit for everything. The default unit in Inkscape is px; you can change that to use pt instead. The only problem is that the font size selector does not currently allow you to choose units, but we'll fix that eventually.
Given that he's doing map stuff, I imagine he's using SVG paths.
Unfortunately it's impossible to specify SVG paths in anything but px, so you really have to stick with px.
The px/pt ratio is not going to be constant with DPI, so if things are specified in pt they won't line up with the paths properly if rendered with a different DPI.
-mental
On 6/5/05, MenTaLguY <mental@...3...> wrote:
The px/pt ratio is not going to be constant with DPI, so if things are specified in pt they won't line up with the paths properly if rendered with a different DPI.
Do you know of any SVG renderer that really changes its px/pt ratio to match DPI? I know of none.
On 6/6/05, mental@...3... <mental@...3...> wrote:
Do you know of any SVG renderer that really changes its px/pt ratio to match DPI? I know of none.
No, but they all pick different base DPIs anyway.
Yes, so your warning should be instead: "The px/pt ratio is not going to be constant with _renderer_". Which basically means, it can't be relied upon at all, period. Mentioning DPI may give the user some expectations which won't realize.
On Monday 06 Jun 2005 01:06, Jon A. Cruz wrote:
This is a bit of a tricky area, as I believe that once we change things to follow the specs even closer, it would entail getting the DPI from the runtime display environment (though if not done properly, things would quickly devolve into chaos)
Jon, maybe I'm misinterpreting what you've said, but you seem to be suggesting that this part is quite a low priority.
It seems to me that respecting display DPI is pretty important. AFAIK, MS Windows, X11, and OS X all provide DPI information, so it seems strange to ignore that and display with the incorrect sizes. Ignoring a 20% size difference is much like ignoring a 20% color difference, to me.
The display units thing is also strange to me. Does the spec actually say that you can't choose to use any other units by default, or simply that if you don't specify anything else *in the file*, it defaults to screen units?
Wouldn't it be best to save in absolute units that are cross-platform compatible, unless someone chooses "export to web..." or "export for display..." or something like that? That way, it would be much easier for people to share work across platforms (important for the Open Content movement), and you could also add optimisation to the export to web option. I haven't read that part of the spec though, so I appreciate it may be something unchangeable.
I'm not the expert here, of course, so please just take these comments as the thoughts that they are ;)
On Jun 6, 2005, at 12:47 AM, Lee Braiden wrote:
Jon, maybe I'm misinterpreting what you've said, but you seem to be suggesting that this part is quite a low priority.
Well... not so much that it's a low priority in and of itself... but rather that a) getting all details for everyone to agree on the best course of action is a bit tricky, and b) researching all the pertinent specs and API's is highly complex.
It seems to me that respecting display DPI is pretty important. AFAIK, MS Windows, X11, and OS X all provide DPI information, so it seems strange to ignore that and display with the incorrect sizes.
Well...
Actually... the values returned by those are often wildly off.
Among other things, that's much of why the Gimp first has a default DPI, second allows you to accept the DPI from the X11 server, but then third has a ruler display so that you can tune it yourself.
Ignoring a 20% size difference is much like ignoring a 20% color difference, to me.
Well... it's not quite ignoring. It's more saying "we aren't doing variable display unless you turn it on". And by default, most people don't quite miss that feature.
The display units thing is also strange to me. Does the spec actually say that you can't choose to use any other units by default, or simply that if you don't specify anything else *in the file*, it defaults to screen units?
Well... there are several things, but some don't allow for setting anything other than px. Then again, there are some possible actions with viewboxes and such...
Wouldn't it be best to save in absolute units that are cross-platform compatible,
Unfortunately, with SVG there aren't quite such things available to us.
:-(
And much of the specs seems to lead to the paradigm where a box 1" on my screen will be 1" on your screen. But if I'm on a 30" monitor and you're on a 12" laptop that might not be a beneficial effect at all.
Jon wrote
Ignoring a 20% size difference is much like ignoring a 20% color difference, to me.
Well... it's not quite ignoring. It's more saying "we aren't doing variable display unless you turn it on". And by default, most people don't quite miss that feature.
What does this man? Does it mean I can turn variable display on? If so how/where?
or does it mean I would not miss the feature if it was there????
Erik
In the meantime your 1.25 factor works but Bulias suggestion to change units to pt seems not to.
Hey guys!
With this thread we've hit some seriously tough discussion: Units. The SVG-spec as I understand it suggests pixels (relative units) as default unit but also allows absolute units within the SVG. Personally I strongly favour absolute units, because given that you know the resolution of your output medium you get the same results for any output medium. A 10mm x 10mm box will (at 100% zoom) be exactly 10mm x 10 mm, no matter if you print it, or see it on screen. This is quite desirable esp. in the field of DTP.
As for icons or web graphics this would make it hard to actually pixel-align elements within the SVG, since on different screens they will, while having the same absolute size, have different sizes in pixels. To some extent it is however beneficial because with the size of pixels on a computer decreasing, icons become smaller and smaller, which may cause drawbacks in terms of usability.
I believe that any SVG should either be using absolute units solely or relative units solely, but one should have the choice between those two. When absolute units are chosen, the display size in pixels is determined by the resolution (DPI) of the outputting media (printer, screen). When relative units are chosen, the image will always have the same size in terms of displaying dots, while the size in mm varies. For DTP work absolute units are definitely preferable, for work for onscreen display this is a little harder to say... but relative units _might_ be preferable (think of printing out a webpage... all graphics will become tiny, when you use relative units)
What really surprises me about this is that within http://www.w3.org/TR/REC-CSS2/syndata.html#length-units pixels are first introduced as relative units but then in graphic 2 (laserprint vs. screen) they are handles as absolute values, while the relative value is called "dots". This is consistent with what is said about units in http://www.w3.org/TR/SVG11/coords.html [1] but that kinda confuses me the same... I'd think of relative units as "device pixels" and absolute units as "Millimeters"/"real world units"
Well, just some thoughts, I wanted to share...
Take care!
David
[1] Note that at initialization, a user unit in the the initial coordinate system is equivalenced to the parent environment's notion of a px unit. Thus, in the the initial coordinate system, because the user coordinate system aligns exactly with the parent's coordinate system, and because often the parent's coordinate system aligns with the device pixel grid, "5px" might actually map to 5 devices pixels. However, if there are any coordinate system transformation due to the use of transform or viewBox attributes, because "5px" maps to 5 user units and because the coordinate system transformations have resulted in a revised user coordinate system, "5px" likely will not map to 5 device pixels. As a result, in most circumstances, "px" units will not map to the device pixel grid.
Note that <path> elements can't have units in their d attribute.
Thus, I believe the option of using mm or the like as the base unit should be implemented by letting the outermost SVG element have a viewBox attribute, and width & height attributes specified in mm or similar.
Giving users control over the viewBox attribute has previously been discussed on channel. What's the best way of searching the logs? Google didn't work for me.
pjrm.
Quoting David Christian Berg <david@...407...>:
With this thread we've hit some seriously tough discussion: Units. The SVG-spec as I understand it suggests pixels (relative units) as default unit but also allows absolute units within the SVG.
In some places. Some important things (like SVG paths!) can only be specified in px, nothing else.
Basically the other units inherited from CSS2 are not seemingly intended to be used in SVG, except for specifying overall document size and a few other things.
Personally I strongly favour absolute units, because given that you know the resolution of your output medium you get the same results for any output medium.
Unfortunately that's not possible because some things (e.g. paths) can only be specified in "relative" (px) units.
I believe that any SVG should either be using absolute units solely or relative units solely, but one should have the choice between those two.
Talk to the SVG WG about this.
Right now the only workable approach for total resolution-independence is the threefold approach I outlined earlier (to wit: specify document dimensions in absolute units, establish a viewBox, and use nothing but px in the actual document).
-mental
Quoting Lee Braiden <lee_b@...786...>:
The display units thing is also strange to me. Does the spec actually say that you can't choose to use any other units by default, or simply that if you don't specify anything else *in the file*, it defaults to screen units?
It's kind of stupider than that. If you want to get consistent results, there is basically only one way to do it:
* define the document dimensions in your unit of choice
* establish a viewBox on the root element, so that the given width and height will be forced to correspond to the pixel dimensions
* specify everything in the actual document in px, because the viewBox will distort the relationship between px and other units in frustrating ways (and anyway, SVG paths have to be specified in px, so it's the only way to get things to line up reliably)
This is one area of SVG that I am rather less than fond of.
-mental
participants (14)
-
unknown＠example.com -
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
Craig Bradney -
David Christian Berg -
Digital Unleashed -
Erik -
Helge Hielscher -
Jon A. Cruz -
Kevin Wixson -
Lee Braiden -
MenTaLguY -
Peter Moulder