Peter pointed out that LWN is featuring Inkscape on its Front page this week. http://lwn.net/
Bryce
Vector graphics with Inkscape
December 8, 2004
This article was contributed by Joe 'Zonker' Brockmeier.
With the release of Inkscape 0.40, we decided to take a look at the latest release and get up to speed with the status of the project. Inkscape started as a fork of the Sodipodi project, but has evolved into a robust project in its own right. Inkscape is a drawing tool that uses the Scalable Vector Graphics (SVG) specification for its native format, and also exports to PNG, as well as saving in Adobe Illustrator format, PostScript, Encapsulated PostScript and PovRay formats. Inkscape will open or import graphics from Adobe Illustrator and Dia, other programs' SVG documents and a wide array of bitmap graphics formats. Inkscape runs on Linux, Windows and Mac OS X.
We installed the Inkscape static RPM on a SUSE 9.2 system to see what the program is capable of, and whether Inkscape was stable and feature-complete enough for productive use. The Inkscape download page on SourceForge includes source packages, RPMs and Windows binaries.
To test Inkscape we started off by creating basic basic shapes using Inkscape's rectangle and ellipse tools and fiddling with color fills, stroke styles, rotation and so forth just to get a feel for Inkscape's tools. It took about fifteen minutes for this writer to get comfortable with the Inkscape interface.
With an application like Inkscape, using a mouse (or tablet) is almost unavoidable. However, Inkscape's shortcut keys allow the user to perform a lot of actions, such as selecting different tools or raising and lowering an object from one layer to another, from the keyboard -- rather than having to grab the mouse to switch between tools or adjust layers. For example, to toggle the current tool from Inkscape's path tool to the select tool, all that's necessary is to hit the space bar or F1. To move an object up one layer, simply hit "Page Up" or "Page Down" to move it lower.
Speaking of layers, layer management is one of the major new features in Inkscape with the 0.40 release, according to the release notes.
Another new feature in 0.40 is a "text-on-path" feature. This allows the user to conform text to a path -- which is useful for creating interesting logos and other artwork that requires text to wrap text to a shape other than a rectangle. The feature is certainly easy to use. All that's required is to select a path and the text object that is to conform to the path. Rectangles, ellipses and other objects must be converted to a path before the user can wrap text to fit that object. By manipulating that object, the user can change the flow of the text even if the text has been removed from the object or if the object is "invisible" because there is no fill color or stroke color associated with the object. The only thing we couldn't figure out was how to specify a starting point on a path for the text.
We also enjoyed Inkscape's "Trace Bitmap" feature, which allows the user to trace an imported bitmap. By importing a photo or other bitmap, it's possible to create an scalable object that can then be turned into paths or otherwise edited in Inkscape. Inkscape has incorporated the potrace utility for this. The trace bitmap feature works best with line art, but can be used to produce some fun effects with photos or other artwork.
Inkscape's performance and stability are excellent. We created a number of documents using Inkscape, exported our documents and some of the Inkscape tutorials to PNG, EPS and PS, and didn't see any glitches. The program never crashed while we were testing, and all of the features that are currently in Inkscape seem to work as advertised. We did noticed that some detail was lost when exporting to EPS from the tutorials, but this may not be an Inkscape limitation.
Though Inkscape doesn't have a full user manual at this stage, it does include several useful tutorials for basic and advanced concepts when working with Inkscape, as well as an excellent man page. It also features an "Elements of Design" document, which may be useful for users who lack a background in art and design. The Inkscape interface also features context help for most tools as well as context-sensitive tips in the bottom status bar.
For the most part, this writer found the interface to be straightforward and intuitive. The "Vacuum Defs" item under the File menu was a bit of a puzzler at first, though it was finally determined that it was for removing unused information from the defs tags in a document. We presume this is a good thing.
Some of Inkscape's functions can be used without even needing to start the Inkscape GUI. For example, inkscape file.svg -e file.png will convert an SVG file to a PNG. This can be particularly useful for users who wish to convert a number of SVG files into PNG format.
SVG experts can edit an SVG document directly, if they so choose, by using Inkscape's built-in XML editor. Very few users will be likely to need this tool, but it's there for those who need or want to edit a document's elements directly.
Inkscape may not be at the same level of functionality as Adobe Illustrator or Corel Draw, but it's certainly capable of creating some excellent graphics -- even if this writer isn't quite up to the task of fully exploiting its potential. With other open source applications like The Gimp and Scribus, Linux is a serious contender for users who are looking for a desktop publishing platform.
On Wed, 8 Dec 2004, Bryce Harrington wrote:
Date: Wed, 8 Dec 2004 21:09:12 -0800 (PST) From: Bryce Harrington <bryce@...260...> To: inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] Inkscape on LWN
Peter pointed out that LWN is featuring Inkscape on its Front page this week. http://lwn.net/
Bryce
Vector graphics with Inkscape
December 8, 2004
This article was contributed by Joe 'Zonker' Brockmeier.
With the release of Inkscape 0.40, we decided to take a look at the latest release and get up to speed with the status of the project. Inkscape started as a fork of the Sodipodi project, but has evolved into a robust project in its own right.
obligatory Sodipodi comparison ;)
We installed the Inkscape static RPM on a SUSE 9.2 system to see what the program is capable of, and whether Inkscape was stable and feature-complete enough for productive use. The Inkscape download page on SourceForge includes source packages, RPMs and Windows binaries.
static builds were such a good idea.
To test Inkscape we started off by creating basic basic shapes using Inkscape's rectangle and ellipse tools and fiddling with color fills, stroke styles, rotation and so forth just to get a feel for Inkscape's tools. It took about fifteen minutes for this writer to get comfortable with the Inkscape interface.
That seems a bit long.
With an application like Inkscape, using a mouse (or tablet) is almost unavoidable.
really? I hope that inkscape will be fairly usable for people with only a mouse but I dont think we are any worse here than any other graphics software.
However, Inkscape's shortcut keys allow the user to perform a lot of actions, such as selecting different tools or raising and
who lack a background in art and design. The Inkscape interface also features context help for most tools as well as context-sensitive tips in the bottom status bar.
For the most part, this writer found the interface to be straightforward and intuitive. The "Vacuum Defs" item under the File menu was a bit of a puzzler at first, though it was finally determined that it was for removing unused information from the defs tags in a document. We presume this is a good thing.
*cough* told-you-so *cough*
It is unusual to have a menu item that to the average use has no noticable effect and if this is really necessary I think it would work better as a global preference.
Some of Inkscape's functions can be used without even needing to start the Inkscape GUI. For example, inkscape file.svg -e file.png will convert an SVG file to a PNG. This can be particularly useful for users who wish to convert a number of SVG files into PNG format.
-e for export presumably
Dia uses -e too gimp doesn't have an equivilent command line option abiword uses --to=format or -t
It is a good sign that Dia and Inkscape have the same arguments for this functionality, might be worth encouraging other projects to do similarly.
SVG experts can edit an SVG document directly, if they so choose, by using Inkscape's built-in XML editor. Very few users will be likely to need this tool, but it's there for those who need or want to edit a document's elements directly.
It is a very good sign that the author doesn't consider it necessary to use the XML Source Editor.
Inkscape may not be at the same level of functionality as Adobe Illustrator or Corel Draw, but it's certainly capable of creating some excellent graphics -- even if this writer isn't quite up to the task of fully exploiting its potential. With other open source applications like The Gimp and Scribus, Linux is a serious contender for users who are looking for a desktop publishing platform.
The good publicity continues.
- Alan
On Fri, 10 Dec 2004, Alan Horkan wrote:
To test Inkscape we started off by creating basic basic shapes using Inkscape's rectangle and ellipse tools and fiddling with color fills, stroke styles, rotation and so forth just to get a feel for Inkscape's tools. It took about fifteen minutes for this writer to get comfortable with the Inkscape interface.
That seems a bit long.
It seems consistent with my experience showing it to one of my graphic artist friends a couple days ago (who is a contributor himself, via a patch and an OS X launcher, but has been away from either project for a long time).
Many of the dialogs and context menus need some heavy usability work.
and intuitive. The "Vacuum Defs" item under the File menu was a bit of a puzzler at first, though it was finally determined that it was for removing unused information from the defs tags in a document. We presume this is a good thing.
*cough* told-you-so *cough*
It is unusual to have a menu item that to the average use has no noticable effect and if this is really necessary I think it would work better as a global preference.
It needs to be invoked manually if at all, otherwise it can have some really painful consequences for certain kinds of users if it's done automatically (particularly on save, which is the time where the consequences are most likely to be unrecoverable).
Now, where it should go is as a button or something in a "defs manager" or "library" dialog, where its function is immediately relevent and apparent (since you could immediately see the unused stuff disappearing).
It's just on the file menu because it's necessary for some users, but we don't have any such dialog to put it yet.
-mental
Many of the dialogs and context menus need some heavy usability work.
Especially the context menus (Kees, where are you? :)
and intuitive. The "Vacuum Defs" item under the File menu was a bit of a
Now, where it should go is as a button or something in a "defs manager" or "library" dialog, where its function is immediately relevent and apparent (since you could immediately see the unused stuff disappearing).
Agreed.
For the most part, this writer found the interface to be straightforward and intuitive. The "Vacuum Defs" item under the File menu was a bit of a puzzler at first, though it was finally determined that it was for removing unused information from the defs tags in a document. We presume this is a good thing.
*cough* told-you-so *cough*
It is unusual to have a menu item that to the average use has no noticable effect
Why, there is at least the effect of saying in the statusbar either "No unused items in <defs>" or "5 unused items deleted in <defs>", when you invoke it.
and if this is really necessary I think it would work better as a
global preference.
Some of Inkscape's functions can be used without even needing to start the Inkscape GUI. For example, inkscape file.svg -e file.png will convert an SVG file to a PNG. This can be particularly useful for users who wish to convert a number of SVG files into PNG format.
-e for export presumably
Dia uses -e too gimp doesn't have an equivilent command line option abiword uses --to=format or -t
It is a good sign that Dia and Inkscape have the same arguments for this functionality, might be worth encouraging other projects to do similarly.
SVG experts can edit an SVG document directly, if they so choose, by using Inkscape's built-in XML editor. Very few users will be likely to need this tool, but it's there for those who need or want to edit a document's elements directly.
It is a very good sign that the author doesn't consider it necessary to use the XML Source Editor.
Inkscape may not be at the same level of functionality as Adobe Illustrator or Corel Draw, but it's certainly capable of creating some excellent graphics -- even if this writer isn't quite up to the task of fully exploiting its potential. With other open source applications like The Gimp and Scribus, Linux is a serious contender for users who are looking for a desktop publishing platform.
The good publicity continues.
- Alan
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, 10 Dec 2004, bulia byak wrote:
Date: Fri, 10 Dec 2004 18:41:59 -0500 From: bulia byak <buliabyak@...400...> To: Alan Horkan <horkana@...44...> Cc: Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Inkscape on LWN
For the most part, this writer found the interface to be straightforward and intuitive. The "Vacuum Defs" item under the File menu was a bit of a puzzler at first, though it was finally determined that it was for removing unused information from the defs tags in a document. We presume this is a good thing.
*cough* told-you-so *cough*
It is unusual to have a menu item that to the average use has no noticable effect
Why, there is at least the effect of saying in the statusbar either "No unused items in <defs>" or "5 unused items deleted in <defs>", when you invoke it.
The statusbar is only for non-essential information and because it can be hidden you cannot assume the statusbar will be showing and rely on it as the only form of user visible feedback.
I'm still unclear as to why someone would want to manually invoke this feature every so often rather than have it on (or off) all the time, or have it tied to save/export (so unused objects would not get written and files would be smaller). Reading the rest of the thread and noting the comments made by Mentalguy I want to make it clear that I meant to think of this as an option at save time, not that it would be done automatically without warning.
Perhaps the author of the article can tell us why he thought the feature was unusual or confusing enough to be worth mentioning.
I said I thought it was a bad idea as soon as I saw and now an independant reviewer is saying it too, so I hope you will reconsider how this is implemented which should be easier than trying to fix me and other users who don't think it makes sense.
Another issue I am having is with the how the tool options palette works at the moment. First let me say that it is a great way to provide easy to find context information for each tool and it does that job rather well. My problem is with trying to use it the 'tool options' to set the properties of the current object. From seeing how similar tool options palettes in other programs work and because I associate those options firmly with the tool, it is very confusing to try and use it to change the current object. The mental model doesn't make sense to me. Other applictions would/do leave open (their equivalent of) the Fill and Stroke dialog and it would be more obvious where to go to change the properties of the currently selected object(s) but if Inkscape were to have a permanently open palette for that kind of formatting it would probably need to be simpler and more compact than the current version. That said it was an understandable change to make and worth trying out. Certainly when I was getting started I recall creating objects and then afterwards changing the tool settings and wondering why the still current object did not change with them. I hope I have described adquately what I mean here, but if I haven't I hope users who are familiar with how other software that uses a tool options palette will help elaborate and help describe quite how unusual the overloaded tool options palette in Inkscape feels.
I know I'm not a usability expert but (I know what I like and) I would strongly encourage you to try asking some one who is, the gnome usability mailing list mailto:usability@...45... is a good place to ask as it includes some people who work on usability at Sun Microsystmes and other real experts.
I have some project and assignment to do and may have part time employment over christmas but if I can help by producing mockup in glade or by gathering screenshots and descriptions of how other applictions work I hope I can help out (if there are any specifics people want please let me know).
- Alan H. http://advogato.org/person/AlanHorkan/
Perhaps the author of the article can tell us why he thought the feature was unusual or confusing enough to be worth mentioning.
I think the only thing slightly confusing about it is the name. But SVG has <defs>, and we just use its terminology because we are an SVG app. And "vacuum" is very descriptive for what it does.
I said I thought it was a bad idea as soon as I saw and now an independant reviewer is saying it too, so I hope you will reconsider how this is implemented which should be easier than trying to fix me and other users who don't think it makes sense.
Other users think it makes a lot of sense. It was even suggested to provide this command as a command line option, which I'm going to do.
Another issue I am having is with the how the tool options palette works at the moment. First let me say that it is a great way to provide easy to find context information for each tool and it does that job rather well. My problem is with trying to use it the 'tool options' to set the properties of the current object. From seeing how similar tool options palettes in other programs work and because I associate those options firmly with the tool, it is very confusing to try and use it to change the current object.
If you're talking about the panel above the canvas, then it's not "tool options." Use the correct terminology and you won't have this problem :) This thing is called "tool controls" now, and it provides exactly this - additional controls for the tool. As for tool options, they're in a different place, namely in the Inkscape Preferences dialog.
Other applictions would/do leave open (their equivalent of) the Fill and Stroke dialog and it would be more obvious where to go to change the properties of the currently selected object(s)
Sure, eventually there will be a color palette at the bottom of the window for this.
Certainly when I was getting started I recall creating objects and then afterwards changing the tool settings and wondering why the still current object did not change with them. I hope I have described adquately what I mean here,
Sorry, no. I'm confused. Can you please be more specific and use only the terminology and labels that Inkscape itself uses, so we could understand what you are referring to?
On Sat, 11 Dec 2004, bulia byak wrote:
Date: Sat, 11 Dec 2004 08:17:13 -0500 From: bulia byak <buliabyak@...400...> To: Alan Horkan <horkana@...44...> Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Usability, Vacuum Defs and Tool options. [Re: [Inkscape-devel] Inkscape on LWN]
Perhaps the author of the article can tell us why he thought the feature was unusual or confusing enough to be worth mentioning.
I think the only thing slightly confusing about it is the name. But SVG has <defs>, and we just use its terminology because we are an SVG app. And "vacuum" is very descriptive for what it does.
I said I thought it was a bad idea as soon as I saw and now an independant reviewer is saying it too, so I hope you will reconsider how this is implemented which should be easier than trying to fix me and other users who don't think it makes sense.
Other users think it makes a lot of sense.
I'm not disagreeing that the functionality makes sense (at least not anymore) just how it is exposed to users.
It was even suggested to provide this command as a command line option, which I'm going to do.
looks like people need an SVG equivalent to HTML tidy, which I can understand because like I said the feature is good just not the interface.
Another issue I am having is with the how the tool options palette works at the moment. First let me say that it is a great way to provide easy to find context information for each tool and it does that job rather well. My problem is with trying to use it the 'tool options' to set the properties of the current object. From seeing how similar tool options palettes in other programs work and because I associate those options firmly with the tool, it is very confusing to try and use it to change the current object.
If you're talking about the panel above the canvas, then it's not "tool options."
The equivlent functionality in Adobe Photoshop is called the "Tool Options Palette" and in the Gnu Image Manipulation Program it is called the "Tool Options Dialog". Similarly with Jasc Web Draw it is called the tools options palette.
Unusually Xara X calls this the "Infobar". (Xara also has a Standard Toolbar with New,Save,etc on it http://www.xaraxone.com/webxealot/xealot16/html/features.htm )
Use the correct terminology and you won't have this problem :)
You may find that amusing but I don't.
You are assuming that the terminlogy used for Inkscape is the most correct, which is not an assumption I'm willing to make.
This thing is called "tool controls" now, and it provides exactly this - additional controls for the tool.
Semantics aside the point is even you are talking about the tools, not formatting the object properties after they have been created. While it works, it is not as logical as how it is done in other programs (like Adobe Photoshop) and it makes the tools a little more complicated.
Other applictions would/do leave open (their equivalent of) the Fill and Stroke dialog and it would be more obvious where to go to change the properties of the currently selected object(s)
Sure, eventually there will be a color palette at the bottom of the window for this.
As these auxilliary palettes/dialog improve I hope the overloading and complication of the "tool controls" to also change the properties of the currently selected object wont be necessary.
Sincerely
Alan Horkan
Inkscape, Draw Freely http://inkscape.org Abiword is Awesome http://abisource.com
If you're talking about the panel above the canvas, then it's not "tool options."
The equivlent functionality in Adobe Photoshop is called the "Tool Options Palette" and in the Gnu Image Manipulation Program it is called the "Tool Options Dialog". Similarly with Jasc Web Draw it is called the tools options palette.
Good for them. So what?
I see no sense in calling this "options" if it's not. It's just an extension of the current tool, its additional controls.
Use the correct terminology and you won't have this problem :)
You may find that amusing but I don't.
You are assuming that the terminlogy used for Inkscape is the most correct, which is not an assumption I'm willing to make.
I'm assuming that the terminology used for Inkscape was chosen with Inkscape in mind and reflects the developers' idea of its functionality.
This thing is called "tool controls" now, and it provides exactly this - additional controls for the tool.
Semantics aside the point is even you are talking about the tools, not formatting the object properties after they have been created.
Tools do exactly that: create objects and modify them. So, modifying objects is what a tool's controls do. What is wrong here?
While it works, it is not as logical as how it is done in other programs (like Adobe Photoshop) and it makes the tools a little more complicated.
I disagree. Sodipodi had nothing like our tool controls, but it had "tool opions" like you propose. It was INCREDIBLY inconvenient to not be able to easily change the selected objects. It was one of the worst aspects of Sodipodi interface that I wanted to change, and it became one of the first things we changed, long ago.
Sure, eventually there will be a color palette at the bottom of the window for this.
As these auxilliary palettes/dialog improve I hope the overloading and complication of the "tool controls" to also change the properties of the currently selected object wont be necessary.
I surely hope not. Your input is appreciated, but I think you'll need to present much more persuasive use cases and usability arguments to overturn this. It's been that way for a long time and it's the first time ever that I see someone being unhappy about the possibility to change all aspects of (any number of) selected object(s) using precise tool controls. It's not "overloading and complication"; it's the primary function of the tool controls.
On Sat, 11 Dec 2004, bulia byak wrote:
Date: Sat, 11 Dec 2004 12:55:27 -0500 From: bulia byak <buliabyak@...400...> To: Alan Horkan <horkana@...44...> Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Usability, Vacuum Defs and Tool options. [Re: [Inkscape-devel] Inkscape on LWN]
Semantics aside the point is even you are talking about the tools, not formatting the object properties after they have been created.
Tools do exactly that: create objects and modify them.
^^^^^^^^^^^^^
the node tool modifies existing objects the select tool modifies existing object but they are the exception and they do not create or add new objects only modify existing ones and logicallly seperated from the ones that do like the line drawing tool, the rectangle tool, the polygon tool, the ellipse tool which should all be for creating new shapes.
So, modifying objects is what a tool's controls do. What is wrong here?
It is what a tools controls do in Inkscape. It works but I dont think it is as logical and clear and easy to learn as how other software manages their tools.
While it works, it is not as logical as how it is done in other programs (like Adobe Photoshop) and it makes the tools a little more complicated.
I disagree. Sodipodi had nothing like our tool controls, but it had "tool opions" like you propose. It was INCREDIBLY inconvenient to not be able to easily change the selected objects. It was one of the worst aspects of Sodipodi interface that I wanted to change, and it became one of the first things we changed, long ago.
My point is the difficulty in changing already created objects is the problem.
I think the current attempt to solve them by overloading the tools is not the best way to fix that problem but for the short term does make things more functional but in the long run I dont think the logic behind it is clear enough and it will make Inkscape less easy to learn. I hate it when people misrepresent wanting thing to be done better as rejecting the entire functionality rather than just the implementation, of course I want to be able to reformat multiple existing objects.
The way other programs have the logical seperation of the tool and their options/controls from how you to format already created objects or groups of objects makes much more sense to me than going through the tools.
Does anyone besides bulia get what I am trying to say and why this might not be the best way to manipulate arleady created objects?
- Alan
On Sat, 2004-12-11 at 13:20, Alan Horkan wrote:
I think the current attempt to solve them by overloading the tools is not the best way to fix that problem but for the short term does make things more functional but in the long run I dont think the logic behind it is clear enough and it will make Inkscape less easy to learn.
That may be true, but in absence of an immediate better idea the perfect is the enemy of the good.
Becoming stuck in a merely local maximum of usability is a legitimate concern, but we can't let that concern paralyze us.
I hate it when people misrepresent wanting thing to be done better as rejecting the entire functionality rather than just the implementation, of course I want to be able to reformat multiple existing objects.
If one persistently advocates the removal of a feature without proposing an alternative, it does tend to come across as a rejection of the functionality that feature offers.
Does anyone besides bulia get what I am trying to say and why this might not be the best way to manipulate arleady created objects?
Yes. Overloading the drawing tools to perform post-creation modifications introduces some level of inconsistency in the interface.
I don't disagree (though I think the inconsistency is minimal), but I've not seen any better suggestions either.
Do you have a better suggestion?
-mental
Yes. Overloading the drawing tools to perform post-creation modifications introduces some level of inconsistency in the interface.
I don't disagree (though I think the inconsistency is minimal), but I've not seen any better suggestions either.
I don't see any inconsistency here at all. The principle is simple: each drawing tool draws objects of its own type, but can edit as many other objects and aspects as practical. E.g. ellipse tool can edit all other shapes, as well as pattern fills. When we move gradient editing to canvas, shape tools and node tool will be able to edit them too, though we will also have a new gradient tool for _creating_ gradients.
Think of it this way: various on-canvas handles are the property of the _object_, not of the _tool_. The shape tools just "allow" objects to reveal their on-canvas editability. I think this is quite consistent and VERY convenient.
Open up Inkscape and type some text at a font size of say 30. Then change the font size to 64 and type another piece of text. OK. Then go and select either of the pieces of text and hit the "Text and Font" dialog and you get the correct font size indicated. However, scale either of the bits of text (larger or smaller) and then inspect them with the dialog. It still indicates the original size. This is not a bug I guess, but it raises the question of how can I tell what size my font is after scaling? I could put it in as an RFE but there may be a workaround or some way that I'm not familiar with-any suggestions?
Both Corel Draw and Xara show the new scaled size as it changes.
Another problem that comes up frequently is that when I have rescaled several bits of text (these are on maps) I finally want to get them all to be the same font size. Is this possible? Ideally I'd like to say have them all at a font size of 8 but how to do it? The dropper does not work with text. Can it be done? or should I put that in as an RFE as well?
vellum
On Tue, 14 Dec 2004 20:51:41 +1100, vellum <kaver@...68...> wrote:
Open up Inkscape and type some text at a font size of say 30. Then change the font size to 64 and type another piece of text. OK. Then go and select either of the pieces of text and hit the "Text and Font" dialog and you get the correct font size indicated. However, scale either of the bits of text (larger or smaller) and then inspect them with the dialog. It still indicates the original size. This is not a bug I guess, but it raises the question of how can I tell what size my font is after scaling? I could put it in as an RFE but there may be a workaround or some way that I'm not familiar with-any suggestions?
Yeah. I've been meaning to change that since forever. Will do now. Scaling text must change its font size. Thanks for reminding me :)
Another problem that comes up frequently is that when I have rescaled several bits of text (these are on maps) I finally want to get them all to be the same font size. Is this possible? Ideally I'd like to say have them all at a font size of 8 but how to do it? The dropper does not work with text. Can it be done? or should I put that in as an RFE as well?
Once the scaled text will have its font size correspondingly set I guess that won't be a problem anymore.
vellum wrote:
Another problem that comes up frequently is that when I have rescaled several bits of text (these are on maps) I finally want to get them all
to
be the same font size. Is this possible? Ideally I'd like to say have
them
all at a font size of 8 but how to do it? The dropper does not work with text. Can it be done? or should I put that in as an RFE as well?
bulia wrote:
Once the scaled text will have its font size correspondingly set I guess that won't be a problem anymore.
Yes. It will still be a problem. The unifying of font size comes at the end of the operation. Lets say there are 100 individual bits of text. Not unusual in a reasonable sized map. They will have a variety of sizes..maybe 100 on a bad day! OK. I decide to have a subset of 87 of them at font size 8. I sure as blazes do not want to individually pick each one and rescale to 8. I can group the 87 but what then??
vellum.
On Tue, Dec 14, 2004 at 09:11:00PM +1100, vellum wrote:
[How do I use a common font size/style for 100 pieces of text;] I can group [them] but what then??
There are a couple of solutions I'd like to suggest, but neither works in Inkscape currently.
- Select each of the text elements you're interested in changing. The font dialog box would indicate that some of the properties vary among the selected items. You'd change the font size from `varying' to `10px'.
- After grouping them, change the font size of the group. If necessary, click a button to make all children/all descendents of the group have the same font size.
The current version of inkscape does something similar with colour (and probably all fill & stroke properties, I haven't checked). It applies the selected fill colour to all descendents of the group.
As neither of the above exist in current Inkscape, I'll have to make a third suggestion: Group them, save & close the document, then use a text editor to remove all occurrences of `font-size:[0-9]*;' from the descendents of that <g> element (i.e. everything between the `<g>' and its matching `</g>'). Then open it with inkscape again. Whenever you change the font-size of the g element (using the XML editor), the descendents of that g element will change accordingly.
Unfortunately, inkscape doesn't allow setting font-size or other properties to explicitly blank or `inherit' other than using the XML editor.
Also unfortunately, font-size and most other properties default to non-blank, resulting large style strings and difficulty in using <g> elements to make lots of items inherit a common property value.
pjrm.
[How do I use a common font size/style for 100 pieces of text;] I can group [them] but what then??
There are a couple of solutions I'd like to suggest, but neither works in Inkscape currently.
- Select each of the text elements you're interested in changing. The font dialog box would indicate that some of the properties vary among the selected items. You'd change the font size from `varying' to `10px'.
This actually works, though not perfect. The dialog shows 12pt (default) instead of "varying". But if you select a different font size and click Apply, it will change font size of all selected objects. Why are you saying it does not work?
- After grouping them, change the font size of the group. If necessary, click a button to make all children/all descendents of the group have the same font size.
This won't work because each text has its own font size and does not inherit from the group.
The current version of inkscape does something similar with colour (and probably all fill & stroke properties, I haven't checked). It applies the selected fill colour to all descendents of the group.
Yes, most code that sets style now uses desktop-style.cpp functions which apply style recursively (and do many other relevant things, such as set the current style). The text dialog is an exception so far, but I'll fix it.
Also you missed another simple way to do this: select one text object, copy, then select all of them and paste style (Ctrl+Shift+V).
As neither of the above exist in current Inkscape, I'll have to make a third suggestion: Group them, save & close the document, then use a text editor to remove all occurrences of `font-size:[0-9]*;' from the descendents of that <g> element (i.e. everything between the `<g>' and its matching `</g>'). Then open it with inkscape again. Whenever you change the font-size of the g element (using the XML editor), the descendents of that g element will change accordingly.
This is unnecessary, as there are at least two other ways to achieve this. The only advantage is that this will let you change the style of many objects by editing one style= string. But even if you need this, a much better way to achieve this is to implement out-of-line CSS references, instead of inheriting style from parents.
Unfortunately, inkscape doesn't allow setting font-size or other properties to explicitly blank or `inherit' other than using the XML editor.
I was just going to add "unspecified" button to fill&stroke for exactly this - removing any fill or stroke specifications from the style. This will allow us to make colored clones - you set "unspecified" fill on the original, and then you can apply any fill to its clones independently.
Also unfortunately, font-size and most other properties default to non-blank, resulting large style strings and difficulty in using <g> elements to make lots of items inherit a common property value.
That's because our style strings are not for reading or writing manually. They're generated and parsed automatically. Most people are not interested in the exact content of style= strings; they are interested in an application whose behavior makes sense in all situations. So for them, providing default property values is far from "unfortunate".
I've been playing with win32 build041214. None of these common style suggestions works for what I want.
They certainly can bring the font size back to a common style. However the text pieces are still scaled and font size does not affect this. What does? Maybe bulias latest stuff which I cannot get at yet.
To simplify. Take a word originally written at a font size of say 30pt. Duplicate it. Scale the duplicate to some size using handles. The dialog still says that font is 30pt. How do I get this back to looking like it was originally written. Ie how to remove scaling effect?
The font sizing and resizing works but I cannot find anything about scaling conditions after scaling or how to reverse it.
Seems to me that the Scale section in the Transform dialog should show the scaled values of a piece of text? In other words if I scale a word by 200% and then come back to it later with the Transform dialog I should see 200% in the windows.
Or am I just being dense? Not unexpected this close to a new year.
vellum
----- Original Message ----- From: "bulia byak" <buliabyak@...400...> To: "Peter Moulder" <Peter.Moulder@...38...>; "vellum" <kaver@...68...>; inkscape-devel@lists.sourceforge.net Sent: Thursday, December 16, 2004 12:01 AM Subject: Re: applying a common style Re: [Inkscape-devel] Re: Font size after scaling?
[How do I use a common font size/style for 100 pieces of text;] I can group [them] but what then??
There are a couple of solutions I'd like to suggest, but neither works in Inkscape currently.
- Select each of the text elements you're interested in changing. The font dialog box would indicate that some of the properties vary among the selected items. You'd change the font size from `varying' to `10px'.
This actually works, though not perfect. The dialog shows 12pt (default) instead of "varying". But if you select a different font size and click Apply, it will change font size of all selected objects. Why are you saying it does not work?
- After grouping them, change the font size of the group. If necessary, click a button to make all children/all descendents of the group have the same font size.
This won't work because each text has its own font size and does not inherit from the group.
The current version of inkscape does something similar with colour (and probably all fill & stroke properties, I haven't checked). It applies the selected fill colour to all descendents of the group.Yes, most code that sets style now uses desktop-style.cpp functions which apply style recursively (and do many other relevant things, such as set the current style). The text dialog is an exception so far, but I'll fix it.
Also you missed another simple way to do this: select one text object, copy, then select all of them and paste style (Ctrl+Shift+V).
As neither of the above exist in current Inkscape, I'll have to make a third suggestion: Group them, save & close the document, then use a text editor to remove all occurrences of `font-size:[0-9]*;' from the descendents of that <g> element (i.e. everything between the `<g>' and its matching `</g>'). Then open it with inkscape again. Whenever you change the font-size of the g element (using the XML editor), the descendents of that g element will change accordingly.
This is unnecessary, as there are at least two other ways to achieve this. The only advantage is that this will let you change the style of many objects by editing one style= string. But even if you need this, a much better way to achieve this is to implement out-of-line CSS references, instead of inheriting style from parents.
Unfortunately, inkscape doesn't allow setting font-size or other properties to explicitly blank or `inherit' other than using the XML
editor.
I was just going to add "unspecified" button to fill&stroke for exactly this - removing any fill or stroke specifications from the style. This will allow us to make colored clones - you set "unspecified" fill on the original, and then you can apply any fill to its clones independently.
Also unfortunately, font-size and most other properties default to non-blank, resulting large style strings and difficulty in using <g> elements to make lots of items inherit a common property value.
That's because our style strings are not for reading or writing manually. They're generated and parsed automatically. Most people are not interested in the exact content of style= strings; they are interested in an application whose behavior makes sense in all situations. So for them, providing default property values is far from "unfortunate".
They certainly can bring the font size back to a common style. However the text pieces are still scaled and font size does not affect this. What does? Maybe bulias latest stuff which I cannot get at yet.
Yes that should fix it, provided you work in optimize mode.
To simplify. Take a word originally written at a font size of say 30pt. Duplicate it. Scale the duplicate to some size using handles. The dialog still says that font is 30pt. How do I get this back to looking like it was originally written. Ie how to remove scaling effect?
In preserve mode, remove the transform= attribute. In optimize mode (with my new code), you will see a different font size for the scaled text, so to get it back just set it to 30pt again.
OK. I got build041215 and the scaling is looking much better. I am using optimise mode and I can get back to my original font size but only when I scale preserving the aspect ratio. Used in this way I can bring groups of different font size text pieces back to a common size on the screen.
However, with non-uniform scaling all hell breaks loose. First. Scaling vertically changes the font size as I would expect. However if I then try to change the font size to the original size then the font dialog font size is correct but the screen presentation is not.
Similarly with scaling horizontally. If I try and go back to the original size using the font dialog then again the font dialog size is correct but the screen presentation is not. As scaling is going on the vertical scale stays at 100% as expected. However, when the text is selected again the font size has changed. I don't believe that it should since the vertical size has not changed.
Similarly with non-uniform scaling in the general case where the aspect ratio is not maintained and both horizontal and vertical scaling are applied.
I like the way in which the new code generates the new percentage information (H and V) as the scaling is proceeding. This operates intuitively but then it disappears. Why not retain it where it is or regenerate it when the text is reselected? It could also be shown in the text dialog along with the font size.
David Bergs idea of "A button "set as 100%" for height and width will then adjust the font-size according to the skewed/streched width or the height respectively. I think this way all needs are served ;)" seems like a good one. Perhaps this could also go in the font dialog ultimately.
A quick look at CorelDraw/XaraX/Canvas/Expression shows a variety of text scaling treatments . But I do not know enough about them to say which is most useful. Maybe David has enough experience with InDesign to help. Certainly the typography people have some good things to say about InDesign and text is Adobes specialty.
vellum
--- Original Message ----- From: "bulia byak" <buliabyak@...400...> To: "vellum" <kaver@...68...> Cc: "Peter Moulder" <Peter.Moulder@...38...>; inkscape-devel@lists.sourceforge.net Sent: Thursday, December 16, 2004 6:24 PM Subject: Re: applying a common style Re: [Inkscape-devel] Re: Font size after scaling?
They certainly can bring the font size back to a common style. However
the
text pieces are still scaled and font size does not affect this. What
does?
Maybe bulias latest stuff which I cannot get at yet.
Yes that should fix it, provided you work in optimize mode.
To simplify. Take a word originally written at a font size of say 30pt. Duplicate it. Scale the duplicate to some size using handles. The dialog still says that font is 30pt. How do I get this back to looking like it
was
originally written. Ie how to remove scaling effect?
In preserve mode, remove the transform= attribute. In optimize mode (with my new code), you will see a different font size for the scaled text, so to get it back just set it to 30pt again.
On Thu, 16 Dec 2004 22:11:16 +1100, vellum <kaver@...68...> wrote:
OK. I got build041215 and the scaling is looking much better. I am using optimise mode and I can get back to my original font size but only when I scale preserving the aspect ratio. Used in this way I can bring groups of different font size text pieces back to a common size on the screen.
However, with non-uniform scaling all hell breaks loose. First. Scaling vertically changes the font size as I would expect. However if I then try to change the font size to the original size then the font dialog font size is correct but the screen presentation is not.
Similarly with scaling horizontally. If I try and go back to the original size using the font dialog then again the font dialog size is correct but the screen presentation is not. As scaling is going on the vertical scale stays at 100% as expected. However, when the text is selected again the font size has changed. I don't believe that it should since the vertical size has not changed.
Similarly with non-uniform scaling in the general case where the aspect ratio is not maintained and both horizontal and vertical scaling are applied.
I like the way in which the new code generates the new percentage information (H and V) as the scaling is proceeding. This operates intuitively but then it disappears. Why not retain it where it is or regenerate it when the text is reselected? It could also be shown in the text dialog along with the font size.
David Bergs idea of "A button "set as 100%" for height and width will then adjust the font-size according to the skewed/streched width or the height respectively. I think this way all needs are served ;)" seems like a good one. Perhaps this could also go in the font dialog ultimately.
A quick look at CorelDraw/XaraX/Canvas/Expression shows a variety of text scaling treatments . But I do not know enough about them to say which is most useful. Maybe David has enough experience with InDesign to help. Certainly the typography people have some good things to say about InDesign and text is Adobes specialty.
In InDesign (as of CS) a size of text doesn't change, if you change its frame size.
Alexandre
In InDesign (as of CS) a size of text doesn't change, if you change its frame size.
That's totally unrelated. We're speaking about scaling text object itself, not its frame (which would make sense only for flowtext).
On Thu, 16 Dec 2004 08:15:04 -0400, bulia byak <buliabyak@...400...> wrote:
In InDesign (as of CS) a size of text doesn't change, if you change its frame size.
That's totally unrelated. We're speaking about scaling text object itself, not its frame (which would make sense only for flowtext).
I'm talking about the fact that InDesign is unrelated here itself ;)
Alexandre
On Do, 2004-12-16 at 15:35 +0300, Alexandre Prokoudine wrote:
On Thu, 16 Dec 2004 08:15:04 -0400, bulia byak <buliabyak@...400...> wrote:
In InDesign (as of CS) a size of text doesn't change, if you change its frame size.
That's totally unrelated. We're speaking about scaling text object itself, not its frame (which would make sense only for flowtext).
I'm talking about the fact that InDesign is unrelated here itself ;)
As Bulia pointed out, it's totally different if I scale the flow-object or the text itself, but think of the text inside a flow-object as scalable. That is what InDesign allows you to do via the Character style menu... you can stretch separate characters vertically and horizontally. Now I'm just talking about the concept of representation here. Take the information of the transformation dialog and put it into the font properties window. An apply behind the v and h stretch spinbox button will change the size to the will calculate the new size using the vertical respectively the horizontal stretch factor. If a flow span can be transformed, this will also work just as in InDesign that you can mark some text and stretch just a few word within a flow-object. So in the big picture, there _is_ a relation to the problem. Just that you can't scale the text as an object in InDesign, doesn't mean you can't stretch it.
Now I'm not sure, how I'd handle groups. They seem to be a problem with any concept because you can't just go along and resize the text within them, because the group still has to be transformed (and therefore the text would show up to large). Maybe if a selected text is within a group that is transformed it should keep it's pt size in the xml but have a size multiplied with the group transformation being displayed? respectively show the group transformation in the spinbox I'd like to introduce and only do the display-cheating when you press apply.
Hmm, that's it for now, got some other stuff to do.
Take care!
David
On Thu, 16 Dec 2004 22:11:16 +1100, vellum <kaver@...68...> wrote:
However, with non-uniform scaling all hell breaks loose. First. Scaling vertically changes the font size as I would expect. However if I then try to change the font size to the original size then the font dialog font size is correct but the screen presentation is not.
Yes, because non-uniform scaling cannot be expressed via font size change. Thus it is factored into two parts, as I explained. When you reset font size to original, you remove only the uniform component of the scale; the non-uniform one remains. I think this is logical.
I honestly don't understand what you are trying to achieve. Imagine you drew a number of equal-sized squares and then scaled them non-uniformly turning them into different rectangles. Now, would you expect there to be an "easy" way to turn them all back to equal-sized squares? I think not. You did what you wanted to them, and now you can only get back by either (1) undo or (2) transforming them again to make them squares. Isn't it logical? It's absolutely the same for text. If you scaled your text non-uniformly and want to get back, do either (1) or (2), exactly the same as with rects. And if (for example) you want different text objects to have the same letter height but different horizontal squeeze, it's easy to achieve that too.
So, can you just explain the final result you're trying to achieve?
I like the way in which the new code generates the new percentage information (H and V) as the scaling is proceeding. This operates intuitively but then it disappears. Why not retain it where it is or regenerate it when the text is reselected? It could also be shown in the text dialog along with the font size.
Because what is stored for an object is not just "scale" but a complete transform which may include rotation, skew, etc. You can look it up in the Object Properties dialog (for now; later I'll probably move it to the Tranformation dialog where it makes more sense).
David Bergs idea of "A button "set as 100%" for height and width will then adjust the font-size according to the skewed/streched width or the height respectively. I think this way all needs are served ;)" seems like a good one. Perhaps this could also go in the font dialog ultimately.
I don't understand still. What will this button do? Just remove the stored transform? Can you explain step-by-step?
Well, now that I think of it, perhaps what you want is for Inkscape to always display and set the "visible" font size, not the font size stored in SVG. This is what is currently done for stroke width: if an object is scaled (either by its own transform= or that of its ancestor group) so that its stroke _looks_ 2pt wide, the Fill & Stroke dialog will be 2pt, even if the source SVG has stroke-width:1pt. However:
(1) I'm not sure this will work for font size the same as it works for stroke width. That's because font size is a vector, not scalar, and it's not always clear how to measure this vector. For example, if your text is skewed, what would you consider its font size: the height perpendicular to the base, or the "length" of skewed letters parallel to the skew? What if this is text on path where each letter is rotated differently, plus they all are skewed and squeezed?
(2) In so far as this is possible, this is _already done_. That was the idea of my latest change: if it is possible to unambiguously factor out the uniform scale component from a transform, it is factored out and applied as font size change; the remainder is applied as a regular transform= as before. This factoring is guaranteed to always work, and it covers the most common practical case of uniform scaling. It _may_ be possible to go further and attempt to factor out (more of) a font size component for a wider class of transforms, such as non-uniform scales and skews, but (a) this is beyond my modest math capabilities at this point; (b) I'm not convinced it is possible in general case; (c) I'm not convinced it will be absolutely "intuitive" (i.e. achieve the ideal match of "how large it looks" and its reported font size) even if we do it.
P.S. Perhaps you noticed the bug: the font size reported in the statusbar in selector for a text object is wrong (unchanged) after scale. This is completely unrelated to the above discussion. Just deselect and reselect it again to see the correct font size.
On Thu, 16 Dec 2004 08:56:04 -0400, bulia byak <buliabyak@...400...> wrote:
This is what is currently done for stroke width: if an object is scaled (either by its own transform= or that of its ancestor group) so that its stroke _looks_ 2pt wide, the Fill & Stroke dialog will be 2pt, even if the source SVG has stroke-width:1pt.
It must be added that, even though currently a non-uniformly scaled object with reported stroke width of 2pt does indeed shows uniform 2pt stroke everywhere, this is in fact a bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=851008&grou...
which must be fixed eventually. And when it is fixed (i.e. when stroke is displayed properly transformed), the match between the reported stroke width and the visible width in different parts of the stroke will be broken for anything but uniform scale, much like it is now broken for anything but uniform scale with text. So this is a universal problem and I'm not sure a universal solution exists.
Thanks for the detailed response bulia. This is valuable stuff and I will have to ponder. But not tonight-I mean this morning. It is 12:17am here. I will be gone until next Tuesday so you can have some peace until then. Basically I'm very happy with the latest changes. I can now do what I originally could not but there are still these little points that I do not understand.
regards, vellum
vellum said:
On Thu, 16 Dec 2004 22:11:16 +1100, vellum <kaver@...68...> wrote:
However, with non-uniform scaling all hell breaks loose. First. Scaling vertically changes the font size as I would expect.
However
if I then try to change the font size to the original size then the font dialog font size is correct but the screen presentation is not.
bulia said:
Yes, because non-uniform scaling cannot be expressed via font size change. Thus it is factored into two parts, as I explained. When you reset font size to original, you remove only the uniform component of the scale; the non-uniform one remains. I think this is logical.
...
So, can you just explain the final result you're trying to achieve?
1. I want to be able to turn a piece of text that has been scaled uniformly or non-uniformly, back to its original state. ie. as it was written.
OK. Your changes allow this to be done with uniformly scaled text. So my original problem is solved.
However, I do not understand what is happening with non-uniform scaling, and it worries me that it simply may be giving the wrong result. The simplest case is where the text is stretched or compressed with no vertical change. The present code changes the font size. Why? I just cannot find anywhere that this is the correct result. As far as I can see the font size should be the same after as before.
XaraX1 operates in the way that I see as correct. It shows two windows for a text object. 1. The font size. 2. The Aspect Ratio which is Width/Height as a percentage. The AR is 100.00 for any font size as initially written.
With non-uniform scaling. The new font size is shown and the AR goes >100 or <100% depending on the scaling. When a piece of text is reselected the new AR and the font size are shown. It is straightforward to set the AR to 100 and the font size to your original font size and you get the original sized text back.
Inkscape cannot not do this.
With horizontal stretching or compressing. With Xarax1 there is no change in font size no matter how much the text width is changed. This is consistent with font size based on letter height. With Inkscape the font size changes with the text width. I think this is wrong.
I do not know the details of what the programs are doing but Xarax seems consistent with
David Bergs idea of "A button "set as 100%" for height and width will
then
adjust the font-size according to the skewed/streched width or the
height
respectively. I think this way all needs are served ;)" seems like a
good
one. Perhaps this could also go in the font dialog ultimately.
I would leave skewed text further down the priority list since I ceratinly do not use it routinely and nobody else has chimed in with this as a need or problem. If I can get non-uniform scaling sorted I'll be happy.
P.S. Perhaps you noticed the bug: the font size reported in the statusbar in selector for a text object is wrong (unchanged) after scale. This is completely unrelated to the above discussion. Just deselect and reselect it again to see the correct font size.
yes.
vellum
Certainly the typography people have some good things to say about InDesign and text is Adobes specialty.
InDesign CS is smooth as hell! There are some things about the top-options-bar that are not quite perfect, but the main drawback is that it doesn't run in Linux ;)
David
vellum wrote:
... how can I tell what size my font is after scaling? I could put it in as an RFE but there may be a workaround or some way that I'm not familiar with-any suggestions?
bulia wrote:
Yeah. I've been meaning to change that since forever. Will do now. Scaling text must change its font size. Thanks for reminding me :)
Thanks, that will be great. However, taking it just a bit further :-). Scaling the text varies the height/width/both. The font size refers to the height. Do you propose also indicating the width changes also? I can see that this might be tricky since for any size change the resultant width could be greater/lesser than the uniformly scaled text width. On the other hand none of the other drawing programs seems to do this and it might be a small feather in our cap or perhaps a barb.
vellum
Thanks, that will be great. However, taking it just a bit further :-). Scaling the text varies the height/width/both. The font size refers to the height. Do you propose also indicating the width changes also? I can see that this might be tricky since for any size change the resultant width could be greater/lesser than the uniformly scaled text width. On the other hand none of the other drawing programs seems to do this and it might be a small feather in our cap or perhaps a barb.
No. Any transform will be factored into two compenents: uniform scale and everything else. The uniform scale will be achieved by scaling the font size, everything else will still be applied as transform= attribute as before. The visible result will be the same.
On Di, 2004-12-14 at 06:37 -0400, bulia byak wrote:
Thanks, that will be great. However, taking it just a bit further :-). Scaling the text varies the height/width/both. The font size refers to the height. Do you propose also indicating the width changes also? I can see that this might be tricky since for any size change the resultant width could be greater/lesser than the uniformly scaled text width. On the other hand none of the other drawing programs seems to do this and it might be a small feather in our cap or perhaps a barb.
No. Any transform will be factored into two compenents: uniform scale and everything else. The uniform scale will be achieved by scaling the font size, everything else will still be applied as transform= attribute as before. The visible result will be the same.
Starting out reading this thread I right away was aware of the problem with non-uniform scaling. However, I actually would introduce a "Font Width" spinbutton for fonts. This is done in InDesign and it's a great tool (e.g. to fake small caps). Since I'd allow changed font widths within flow text, I'm not sure, the transformation will work, nor if there are other means of specifying the width. concerning the scaling in height, I do suggest to _not_ show the new size but also have spinbutton for this showing the percentage of the original height. A button "set as 100%" for height and width will then adjust the font-size according to the skewed/streched width or the height respectively. I think this way all needs are served ;)
Just my 0.02 €
David
Starting out reading this thread I right away was aware of the problem with non-uniform scaling. However, I actually would introduce a "Font Width" spinbutton for fonts.
If you mean by this a way to scale letters non-uniformly without scaling the entire text object, then unfortunately SVG does not allow this. You can shift and rotate letters separately but not transform them arbitrarily. It's one the the gripes of mine. Maybe in a future SVG version.
concerning the scaling in height, I do suggest to _not_ show the new size but also have spinbutton for this showing the percentage of the original height. A button "set as 100%" for height and width will then adjust the font-size according to the skewed/streched width or the height respectively. I think this way all needs are served ;)
I'm not sure what is to be considered the "original height" here. In any case, you can work in the "preserve" mode and then you can return to the original point size by removing the transform= (though I'm not sure why this might be needed).
Anyway, the code for transforms changing point size (in "optimize" mode only) is now in CVS, please test it thoroughly (there may be surprises, as this is a pretty low-level change). The new code also optimizes the translation part of the transform into a change of x/y attributes on text.
bulia byak wrote:
On Tue, 14 Dec 2004 20:51:41 +1100, vellum <kaver@...68...> wrote:
Open up Inkscape and type some text at a font size of say 30. Then change the font size to 64 and type another piece of text. OK. Then go and select either of the pieces of text and hit the "Text and Font" dialog and you get the correct font size indicated. However, scale either of the bits of text (larger or smaller) and then inspect them with the dialog. It still indicates the original size. This is not a bug I guess, but it raises the question of how can I tell what size my font is after scaling? I could put it in as an RFE but there may be a workaround or some way that I'm not familiar with-any suggestions?
Yeah. I've been meaning to change that since forever. Will do now. Scaling text must change its font size. Thanks for reminding me :)
I thought that rendering a font at say 8pt and scaling x2, is not quite the same as rendering a font at 16pt. I'm sure that changing the font size will be what most people want, and is the best default, but keeping transforms as transforms should also be possible too.
John
I thought that rendering a font at say 8pt and scaling x2, is not quite the same as rendering a font at 16pt.
I know only one piece of software where it is not the same: TeX changes letter proportions and shape depending on point size, for its built-in CM fonts. But it's an exception. Modern font formats have no provisions for that, and at least letter shapes are never changed (though some software may e.g. change tracking depending on point size).
[Well, to be pedantic, PFB/TTF fonts can be _hinted_, which will affect the way they are rasterized and thus, one might say, change the "shape" of the letters. But this is irrelevant for a vector tool such as Inkscape, and hinting depends on pixels size, not point size, anyway.]
I'm sure that changing the font size will be what most people want, and is the best default, but keeping transforms as transforms should also be possible too.
Sure, it will obey the same "optimize/preserve transforms" switch as everything else. "Optimize" would change font size, "preserve" would not, using the transform= only.
I thought that rendering a font at say 8pt and scaling x2, is not quite the same as rendering a font at 16pt.
"In the age of metal type, character design and spacing were adjusted for the point size of the font. Smaller size fonts typically had proportionally wider spacing, heavier stems and serifs, and less contrast between thick and thin strokes than larger size fonts." (http://www.prepressure.com/fonts/multiple01.htm, third bullet point, half way through the page).
A font technology that allows such variations to be requested on a continuous scale is "multiple master" fonts. Adobe's multiple master format is dying away (not really supported in MacOS X, Adobe isn't making any new MM fonts, though continues to use them in its products).
That page also notes that Adobe Illustrator 7 and later have "direct built-in support for MM fonts, allowing you to modify MM fonts using a simple slider."
pjrm.
On Wed, Dec 15, 2004 at 10:27:59PM +1100, Peter Moulder wrote:
Adobe's multiple master format is dying away (not really supported in MacOS X, Adobe isn't making any new MM fonts, though continues to use them in its products).
Another implementation of the same idea is usually called "Apple distortable fonts", implemented in TrueType.
FontForge supports both formats: http://fontforge.sourceforge.net/multiplemaster.html
FontForge is Free Software, apparently actively developed, and is distributed in Debian.
pjrm.
On Sun, 12 Dec 2004, MenTaLguY wrote:
Date: Sun, 12 Dec 2004 14:58:29 -0500 From: MenTaLguY <mental@...3...> To: Alan Horkan <horkana@...44...> Cc: Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net, bulia byak <buliabyak@...400...> Subject: Re: [Inkscape-devel] Usability, Vacuum Defs and Tool options. [Re: [Inkscape-devel] Inkscape on LWN]
On Sat, 2004-12-11 at 13:20, Alan Horkan wrote:
I think the current attempt to solve them by overloading the tools is not the best way to fix that problem but for the short term does make things more functional but in the long run I dont think the logic behind it is clear enough and it will make Inkscape less easy to learn.
That may be true, but in absence of an immediate better idea the perfect is the enemy of the good.
I'm afraid I may need to have that mantra tattooed across my forearm but the reminder is appreciated.
If one persistently advocates the removal of a feature without proposing an alternative, it does tend to come across as a rejection of the functionality that feature offers.
I can see how my comments can be read that way but I see it as advocating changes not removing of anything. Clearly I need to try harder to describe what I mean.
Yes. Overloading the drawing tools to perform post-creation modifications introduces some level of inconsistency in the interface.
I don't disagree (though I think the inconsistency is minimal), but I've not seen any better suggestions either.
Do you have a better suggestion?
At the moment the best I can offer is to try and help improve the various palettes and transient dialogs by providing mockups and comparisions.
I really will try to make my comments more productive, so many other distractions I'm not organised enough to contribute much more than commetns at the moment.
- Alan
participants (10)
-
Alan Horkan -
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
David Christian Berg -
John Pybus -
Kees Cook -
MenTaLguY -
Peter Moulder -
vellum