Re: [Inkscape-devel] Text improvements
I'll fine-tooth-comb the various workflows this weekend and make a comparison for reference. Personally, I'd be thrilled if paste-style worked on flowed text again.
Jabier's idea sounds good to me though at a glance.
On 10 Nov 2016 8:02 pm, "Sylvain Chiron" <chironsylvain@...3370...> wrote:
Le 09/11/2016 à 16:15, Jabier Arraiza a écrit :
Sorry for my english, Jabier.
Might be a bit better like that if I understand well:
— Hi all. Today I need to draw something with text and I want to suggest improvements to 0.92 if possible.
1.- Remove the ‘Set as default’ button for text formats (within the Text dialog). It’s hard to use well, usually gives bad results and moreover text default styling is magically changed for the end user. Even knowing how it works, I was wrong several times in text editing for the same doc.
2.- Line height changes do not work correctly if text is selected; it’s hard to change the baseline once text is entered. I ended up copying the text and pasting it into a new text item.
3.- If you change the text size, the baseline is not updated and it comes to the 2nd point. —
Original:
1.- Remove set default text format definition whith only click. Is hard to use well, give usualy bad results and most important text default styling is changed magicaly to the final user. I know it and >
be brong on tenxt editing several times in the same doc.
2.- Line height changes not work correctly if there is selected text, is hard to change baseline once the text is entered, finaly I become coping the text and pasting into a new text item
3.- If you change the size of a text, baseline is not updated and also become to "bug" 2
Do you mean line height changes shouldn’t affect text within a line? -- Sylvain
------------------------------------------------------------ ------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Sorry!!! There is a miss undertand here:
1.- Remove the ‘Set as default’ button for text formats (within the Text dialog). It’
The button in the text tool is perfect, Im speaking on a feature that set the default text if you click with the text tool on the document and, before start typing, change text parameters.
This are stored as default, but to me is more a "bug" than a feature because text defautls are changed magiacaly to the user.
Cheers, Jabier.
On Thu, 2016-11-10 at 20:55 +0000, C R wrote:
I'll fine-tooth-comb the various workflows this weekend and make a comparison for reference. Personally, I'd be thrilled if paste-style worked on flowed text again.
Jabier's idea sounds good to me though at a glance.
On 10 Nov 2016 8:02 pm, "Sylvain Chiron" <chironsylvain@...3370...> wrote:
Le 09/11/2016 à 16:15, Jabier Arraiza a écrit :
Sorry for my english, Jabier.
Might be a bit better like that if I understand well:
— Hi all. Today I need to draw something with text and I want to suggest improvements to 0.92 if possible.
1.- Remove the ‘Set as default’ button for text formats (within the Text dialog). It’s hard to use well, usually gives bad results and moreover text default styling is magically changed for the end user. Even knowing how it works, I was wrong several times in text editing for the same doc.
2.- Line height changes do not work correctly if text is selected; it’s hard to change the baseline once text is entered. I ended up copying the text and pasting it into a new text item.
3.- If you change the text size, the baseline is not updated and it comes to the 2nd point. —
Original:
1.- Remove set default text format definition whith only click. Is hard to use well, give usualy bad results and most important text default styling is changed magicaly to the final user. I know it and >
be brong on tenxt editing several times in the same doc.
2.- Line height changes not work correctly if there is selected text, is hard to change baseline once the text is entered, finaly I become coping the text and pasting into a new text item
3.- If you change the size of a text, baseline is not updated and also become to "bug" 2
Do you mean line height changes shouldn’t affect text within a line?
Sylvain
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Le 11/11/2016 à 10:37, Jabier Arraiza a écrit :
Sorry!!! There is a miss undertand here:
1.- Remove the ‘Set as default’ button for text formats (within the Text dialog). It’
The button in the text tool is perfect, Im speaking on a feature that set the default text if you click with the text tool on the document and, before start typing, change text parameters.
This are stored as default, but to me is more a "bug" than a feature because text defautls are changed magiacaly to the user.
OK. Makes more sense. So:
(1) When you click on the document with the text tool, and change text format before typing anything, default text format is changed accordingly. It shouldn’t.
But I’m testing the feature: if you change the format before typing, you can’t type anymore, you have to click again on the document, means creating a new text object. So the fix should be:
(1) If you change text format in the control bar with the text tool and no text object focused, it should only apply to the next text creation and should not be set as the default text format.
All that explains some weird things I encountered with the text tool… Thanks.
I’m still not sure about the other points. Here is what I understood:
(2) Line height should only be changed for full lines: the control should be disabled/grayed when characters are selected.
(3) The baseline (I guess ‘vertical shift’) should be updated proportionally with text size changes.
I can’t test (3), my controls (kerning, shift and rotation) are keeping disabled when text is focused, I don’t understand why. -- Sylvain
Hi Sylvain. Reply inline
(1) When you click on the document with the text tool, and change text format before typing anything, default text format is changed accordingly. It shouldn’t.
But I’m testing the feature: if you change the format before typing, you can’t type anymore, you have to click again on the document, means creating a new text object. So the fix should be:
(1) If you change text format in the control bar with the text tool and no text object focused, it should only apply to the next text creation and should not be set as the default text format.
YES!
(2) Line height should only be changed for full lines: the control should be disabled/grayed when characters are selected.
Not, I think is best always working the same has or not has selected glyps and the changes apply to the whole text always.
(3) The baseline (I guess ‘vertical shift’) should be updated proportionally with text size changes.
Sure for % line heights, not sure about the others.
I can’t test (3), my controls (kerning, shift and rotation) are keeping disabled when text is focused, I don’t understand why.
All the best, Jabier.
1.- Remove set default text format definition whith only click. Is hard to use well, give usualy bad results and most important text default styling is changed magicaly to the final user. I know it and be brong on tenxt editing several times in the same doc.
2.- Line height changes not work correctly if there is selected text, is hard to change baseline once the text is entered, finaly I become coping the text and pasting into a new text item
3.- If you change the size of a text, baseline is not updated and also become to "bug" 2
Okay, I work with a lot of text all the time. I've kinda accepted that it's a pain in the ass compared to a lot of other programs I've used in the past in a few ways, some of them highlighted by Jabier.
Here are my recommended fixes based on my own text-heavy workflows:
1. Get rid of all concepts of a "default font", and replace with "last used". Most often you just want to use the last font you were using before. It's much easier than trying to define a universal default, forgetting what the default you set is, and having to change a bunch of things around after you see it.
2. Replace that value with the value of the the last font used.
3. Fix ctrl+shift+v to paste the style correctly when a flowed text box is selected, and make it possible to paste style between flowed and non-flowed text. (It's current broken).
4. Use "em" as the default units for spacing between baselines: em is based on the height of the font, and therefore provides a vector-like scaling of spaces between lines during font-size resizing- thus if you change the font-size, you can be sure the line-spacing is going to be the same visual spacing that you just painstakingly adjusted to fit the chosen font. The increment should be changed to a fractional amount of em (0.05) for proper granularity (though 0.1 increment would be okay for most purposes, imho) 1 em is too much of an increment.
If you do these things these problems *should* vanish, and you can remove that button from the text properties, and users can just copy/paste styles from headlines, paragraphs, etc, etc. without having to worry about default fonts.
The only exception to this is of course if Inkscape stores a default font value for the document. In which case, keep the button and load the default font only when the document is opened. This will provide the benefit of a default staring font, without requiring the user to continually sumble over it for the rest of the editing session.
If anyone wants to see workflow diagrams on these points let me know.
Thanks for your work on this, Jabier! -C
On Fri, Nov 11, 2016 at 2:39 PM, Jabier Arraiza <jabier.arraiza@...2893...> wrote:
Hi Sylvain. Reply inline
(1) When you click on the document with the text tool, and change text format before typing anything, default text format is changed accordingly. It shouldn’t.
But I’m testing the feature: if you change the format before typing, you can’t type anymore, you have to click again on the document, means creating a new text object. So the fix should be:
(1) If you change text format in the control bar with the text tool and no text object focused, it should only apply to the next text creation and should not be set as the default text format.
YES!
(2) Line height should only be changed for full lines: the control should be disabled/grayed when characters are selected.
Not, I think is best always working the same has or not has selected glyps and the changes apply to the whole text always.
(3) The baseline (I guess ‘vertical shift’) should be updated proportionally with text size changes.
Sure for % line heights, not sure about the others.
I can’t test (3), my controls (kerning, shift and rotation) are keeping disabled when text is focused, I don’t understand why.
All the best, Jabier.
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi CR. Inkscape store default text in global prefs. In my opinion is ok get rid of default font and use last used as other tools. We need to have a comunity/devel approve to make this changes, Whats the way to it? If we decide change, maybe is cool be done on 0.92.
The "em" is cool, I start using it! Anyway in my designer mind a 100%=1 unit line height, if I change the font size, the line height change and 100% size also change.
Cheers, Jabier.
On Sun, 2016-11-13 at 14:43 +0000, C R wrote:
1.- Remove set default text format definition whith only click. Is hard to use well, give usualy bad results and most important text default styling is changed magicaly to the final user. I know it and be brong on tenxt editing several times in the same doc.
2.- Line height changes not work correctly if there is selected text, is hard to change baseline once the text is entered, finaly I become coping the text and pasting into a new text item
3.- If you change the size of a text, baseline is not updated and also become to "bug" 2
Okay, I work with a lot of text all the time. I've kinda accepted that it's a pain in the ass compared to a lot of other programs I've used in the past in a few ways, some of them highlighted by Jabier.
Here are my recommended fixes based on my own text-heavy workflows:
- Get rid of all concepts of a "default font", and replace with
"last used". Most often you just want to use the last font you were using before. It's much easier than trying to define a universal default, forgetting what the default you set is, and having to change a bunch of things around after you see it.
Replace that value with the value of the the last font used.
Fix ctrl+shift+v to paste the style correctly when a flowed text
box is selected, and make it possible to paste style between flowed and non-flowed text. (It's current broken).
- Use "em" as the default units for spacing between baselines: em is
based on the height of the font, and therefore provides a vector-like scaling of spaces between lines during font-size resizing- thus if you change the font-size, you can be sure the line-spacing is going to be the same visual spacing that you just painstakingly adjusted to fit the chosen font. The increment should be changed to a fractional amount of em (0.05) for proper granularity (though 0.1 increment would be okay for most purposes, imho) 1 em is too much of an increment.
If you do these things these problems *should* vanish, and you can remove that button from the text properties, and users can just copy/paste styles from headlines, paragraphs, etc, etc. without having to worry about default fonts.
The only exception to this is of course if Inkscape stores a default font value for the document. In which case, keep the button and load the default font only when the document is opened. This will provide the benefit of a default staring font, without requiring the user to continually sumble over it for the rest of the editing session.
If anyone wants to see workflow diagrams on these points let me know.
Thanks for your work on this, Jabier! -C
On Fri, Nov 11, 2016 at 2:39 PM, Jabier Arraiza <jabier.arraiza@...2893...> wrote:
Hi Sylvain. Reply inline
(1) When you click on the document with the text tool, and change text format before typing anything, default text format is changed accordingly. It shouldn’t.
But I’m testing the feature: if you change the format before typing, you can’t type anymore, you have to click again on the document, means creating a new text object. So the fix should be:
(1) If you change text format in the control bar with the text tool and no text object focused, it should only apply to the next text creation and should not be set as the default text format.
YES!
(2) Line height should only be changed for full lines: the control should be disabled/grayed when characters are selected.
Not, I think is best always working the same has or not has selected glyps and the changes apply to the whole text always.
(3) The baseline (I guess ‘vertical shift’) should be updated proportionally with text size changes.
Sure for % line heights, not sure about the others.
I can’t test (3), my controls (kerning, shift and rotation) are keeping disabled when text is focused, I don’t understand why.
All the best, Jabier.
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, 2016-11-13 at 19:37 +0100, Jabiertxo Arraiza Cenoz wrote:
Hi CR. Inkscape store default text in global prefs. In my opinion is ok get rid of default font and use last used as other tools. We need to have a comunity/devel approve to make this changes, Whats the way to it? If we decide change, maybe is cool be done on 0.92.
The "em" is cool, I start using it! Anyway in my designer mind a 100%=1 unit line height, if I change the font size, the line height change and 100% size also change.
"em" is NOT what you want if you want the line spacing to increase as you change font size. If you use 'em' or any other unit, the line spacing is fixed to that value (unless you explicitly override it). What you want to use is a unit-less value.
See:
https://developer.mozilla.org/en-US/docs/Web/CSS/line-height
and
http://tavmjong.free.fr/blog/?p=1632
Tav
Cheers, Jabier.
On Sun, 2016-11-13 at 14:43 +0000, C R wrote:
1.- Remove set default text format definition whith only click. Is hard to use well, give usualy bad results and most important text default styling is changed magicaly to the final user. I know it and be brong on tenxt editing several times in the same doc.
2.- Line height changes not work correctly if there is selected text, is hard to change baseline once the text is entered, finaly I become coping the text and pasting into a new text item
3.- If you change the size of a text, baseline is not updated and also become to "bug" 2
Okay, I work with a lot of text all the time. I've kinda accepted that it's a pain in the ass compared to a lot of other programs I've used in the past in a few ways, some of them highlighted by Jabier.
Here are my recommended fixes based on my own text-heavy workflows:
- Get rid of all concepts of a "default font", and replace with
"last used". Most often you just want to use the last font you were using before. It's much easier than trying to define a universal default, forgetting what the default you set is, and having to change a bunch of things around after you see it.
Replace that value with the value of the the last font used.
Fix ctrl+shift+v to paste the style correctly when a flowed text
box is selected, and make it possible to paste style between flowed and non-flowed text. (It's current broken).
- Use "em" as the default units for spacing between baselines: em
is based on the height of the font, and therefore provides a vector- like scaling of spaces between lines during font-size resizing- thus if you change the font-size, you can be sure the line-spacing is going to be the same visual spacing that you just painstakingly adjusted to fit the chosen font. The increment should be changed to a fractional amount of em (0.05) for proper granularity (though 0.1 increment would be okay for most purposes, imho) 1 em is too much of an increment.
If you do these things these problems *should* vanish, and you can remove that button from the text properties, and users can just copy/paste styles from headlines, paragraphs, etc, etc. without having to worry about default fonts.
The only exception to this is of course if Inkscape stores a default font value for the document. In which case, keep the button and load the default font only when the document is opened. This will provide the benefit of a default staring font, without requiring the user to continually sumble over it for the rest of the editing session.
If anyone wants to see workflow diagrams on these points let me know.
Thanks for your work on this, Jabier! -C
On Fri, Nov 11, 2016 at 2:39 PM, Jabier Arraiza <jabier.arraiza@...2893...> wrote:
Hi Sylvain. Reply inline
(1) When you click on the document with the text tool, and change text format before typing anything, default text format is changed accordingly. It shouldn’t.
But I’m testing the feature: if you change the format before typing, you can’t type anymore, you have to click again on the document, means creating a new text object. So the fix should be:
(1) If you change text format in the control bar with the text tool and no text object focused, it should only apply to the next text creation and should not be set as the default text format.
YES!
(2) Line height should only be changed for full lines: the control should be disabled/grayed when characters are selected.
Not, I think is best always working the same has or not has selected glyps and the changes apply to the whole text always.
(3) The baseline (I guess ‘vertical shift’) should be updated proportionally with text size changes.
Sure for % line heights, not sure about the others.
I can’t test (3), my controls (kerning, shift and rotation) are keeping disabled when text is focused, I don’t understand why.
All the best, Jabier.
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
"em" is NOT what you want if you want the line spacing to increase as you change font size. If you use 'em' or any other unit, the line spacing is fixed to that value (unless you explicitly override it).
em in css is supposed to provide a size relative to the font-size... no? I mean that's what I use it for...
So 1em on a 20px font is 20px
therefore: if I change a 20px font to 30px, 1em = 30px if I change it to 180px, 1em = 180px
Sure, it's still just 1em (a fixed value), but what it translates to in terms of px, mm, in, etc is in relation to the font size...
Am I wrong? :)
What you want to use is a unit-less value.
https://developer.mozilla.org/en-US/docs/Web/CSS/line-height
Okay, so the REAL problem is inheritance conflicts associated with em. That's fine with me, then let's use unitless values instead. According to the links posted, under normal circumstances it does the same thing as em (acts as a multiplier to the font-size), but is not affected by inheritance. Fine with me. :)
-C
On Sun, 2016-11-13 at 14:43 +0000, C R wrote:
1.- Remove set default text format definition whith only click. Is hard to use well, give usualy bad results and most important text default styling is changed magicaly to the final user. I know it and be brong on tenxt editing several times in the same doc.
2.- Line height changes not work correctly if there is selected text, is hard to change baseline once the text is entered, finaly I become coping the text and pasting into a new text item
3.- If you change the size of a text, baseline is not updated and also become to "bug" 2
Okay, I work with a lot of text all the time. I've kinda accepted that it's a pain in the ass compared to a lot of other programs I've used in the past in a few ways, some of them highlighted by Jabier.
Here are my recommended fixes based on my own text-heavy workflows:
- Get rid of all concepts of a "default font", and replace with
"last used". Most often you just want to use the last font you were using before. It's much easier than trying to define a universal default, forgetting what the default you set is, and having to change a bunch of things around after you see it.
Replace that value with the value of the the last font used.
Fix ctrl+shift+v to paste the style correctly when a flowed text
box is selected, and make it possible to paste style between flowed and non-flowed text. (It's current broken).
- Use "em" as the default units for spacing between baselines: em
is based on the height of the font, and therefore provides a vector- like scaling of spaces between lines during font-size resizing- thus if you change the font-size, you can be sure the line-spacing is going to be the same visual spacing that you just painstakingly adjusted to fit the chosen font. The increment should be changed to a fractional amount of em (0.05) for proper granularity (though 0.1 increment would be okay for most purposes, imho) 1 em is too much of an increment.
If you do these things these problems *should* vanish, and you can remove that button from the text properties, and users can just copy/paste styles from headlines, paragraphs, etc, etc. without having to worry about default fonts.
The only exception to this is of course if Inkscape stores a default font value for the document. In which case, keep the button and load the default font only when the document is opened. This will provide the benefit of a default staring font, without requiring the user to continually sumble over it for the rest of the editing session.
If anyone wants to see workflow diagrams on these points let me know.
Thanks for your work on this, Jabier! -C
On Fri, Nov 11, 2016 at 2:39 PM, Jabier Arraiza <jabier.arraiza@...2893...> wrote:
Hi Sylvain. Reply inline
(1) When you click on the document with the text tool, and change text format before typing anything, default text format is changed accordingly. It shouldn’t.
But I’m testing the feature: if you change the format before typing, you can’t type anymore, you have to click again on the document, means creating a new text object. So the fix should be:
(1) If you change text format in the control bar with the text tool and no text object focused, it should only apply to the next text creation and should not be set as the default text format.
YES!
(2) Line height should only be changed for full lines: the control should be disabled/grayed when characters are selected.
Not, I think is best always working the same has or not has selected glyps and the changes apply to the whole text always.
(3) The baseline (I guess ‘vertical shift’) should be updated proportionally with text size changes.
Sure for % line heights, not sure about the others.
I can’t test (3), my controls (kerning, shift and rotation) are keeping disabled when text is focused, I don’t understand why.
All the best, Jabier.
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Oh! Now I see I could remove units from combo in inkscape, is the first position but seems in first look a combo problem than a empty value and never use it. Thanks for the clarification Tav.
Cheers, Jabier.
On Sun, 2016-11-13 at 20:12 +0100, Tavmjong Bah wrote:
On Sun, 2016-11-13 at 19:37 +0100, Jabiertxo Arraiza Cenoz wrote:
Hi CR. Inkscape store default text in global prefs. In my opinion is ok get rid of default font and use last used as other tools. We need to have a comunity/devel approve to make this changes, Whats the way to it? If we decide change, maybe is cool be done on 0.92.
The "em" is cool, I start using it! Anyway in my designer mind a 100%=1 unit line height, if I change the font size, the line height change and 100% size also change.
"em" is NOT what you want if you want the line spacing to increase as you change font size. If you use 'em' or any other unit, the line spacing is fixed to that value (unless you explicitly override it). What you want to use is a unit-less value.
See:
https://developer.mozilla.org/en-US/docs/Web/CSS/line-height
and
http://tavmjong.free.fr/blog/?p=1632
Tav
Cheers, Jabier.
On Sun, 2016-11-13 at 14:43 +0000, C R wrote:
1.- Remove set default text format definition whith only click. Is hard to use well, give usualy bad results and most important text default styling is changed magicaly to the final user. I know it and be brong on tenxt editing several times in the same doc.
2.- Line height changes not work correctly if there is selected text, is hard to change baseline once the text is entered, finaly I become coping the text and pasting into a new text item
3.- If you change the size of a text, baseline is not updated and also become to "bug" 2
Okay, I work with a lot of text all the time. I've kinda accepted that it's a pain in the ass compared to a lot of other programs I've used in the past in a few ways, some of them highlighted by Jabier.
Here are my recommended fixes based on my own text-heavy workflows:
- Get rid of all concepts of a "default font", and replace with
"last used". Most often you just want to use the last font you were using before. It's much easier than trying to define a universal default, forgetting what the default you set is, and having to change a bunch of things around after you see it.
Replace that value with the value of the the last font used.
Fix ctrl+shift+v to paste the style correctly when a flowed
text box is selected, and make it possible to paste style between flowed and non-flowed text. (It's current broken).
- Use "em" as the default units for spacing between baselines:
em is based on the height of the font, and therefore provides a vector- like scaling of spaces between lines during font-size resizing- thus if you change the font-size, you can be sure the line-spacing is going to be the same visual spacing that you just painstakingly adjusted to fit the chosen font. The increment should be changed to a fractional amount of em (0.05) for proper granularity (though 0.1 increment would be okay for most purposes, imho) 1 em is too much of an increment.
If you do these things these problems *should* vanish, and you can remove that button from the text properties, and users can just copy/paste styles from headlines, paragraphs, etc, etc. without having to worry about default fonts.
The only exception to this is of course if Inkscape stores a default font value for the document. In which case, keep the button and load the default font only when the document is opened. This will provide the benefit of a default staring font, without requiring the user to continually sumble over it for the rest of the editing session.
If anyone wants to see workflow diagrams on these points let me know.
Thanks for your work on this, Jabier! -C
On Fri, Nov 11, 2016 at 2:39 PM, Jabier Arraiza <jabier.arraiza@...2893...> wrote:
Hi Sylvain. Reply inline
(1) When you click on the document with the text tool, and change text format before typing anything, default text format is changed accordingly. It shouldn’t.
But I’m testing the feature: if you change the format before typing, you can’t type anymore, you have to click again on the document, means creating a new text object. So the fix should be:
(1) If you change text format in the control bar with the text tool and no text object focused, it should only apply to the next text creation and should not be set as the default text format.
YES!
(2) Line height should only be changed for full lines: the control should be disabled/grayed when characters are selected.
Not, I think is best always working the same has or not has selected glyps and the changes apply to the whole text always.
(3) The baseline (I guess ‘vertical shift’) should be updated proportionally with text size changes.
Sure for % line heights, not sure about the others.
I can’t test (3), my controls (kerning, shift and rotation) are keeping disabled when text is focused, I don’t understand why.
All the best, Jabier.
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
In fact, I'd go as far as to say that if the user sets the units to anything other than em or unitless, the spacing should probably stay the same... (as it does now). I mean explicitly setting the line height for something to mm for example, it might be useful to keep that line height no matter what the font size is. So say you're trying to get your flowed text to line up over a set of lines that are 20px apart. Setting the units to px, and changing the value to 20 would allow you to experiment with the font size without changing the baseline of the font (and thus keeping the letters all nice and lined up on those lines. The user can always switch to em or unitless (which I think is a useful default for most people), and changed in the special cases that need fixed line spacing of a particular measure.
In short:
Case 1 (Default): Unit set to unitless (I don't care what the exact measurement is, I just want it to look good, and be able to have the line spacing adjust with the font size)
Case 2 (User changes): Units set to a specific unit of measurement (mm, px, etc) - (I care what the units are because I've set them to something, and I want you to preserve the line height I set, because it's a fixed height, not based off font size)
So both use cases are handled.
-C
On Sun, Nov 13, 2016 at 9:18 PM, C R <cajhne@...400...> wrote:
"em" is NOT what you want if you want the line spacing to increase as you change font size. If you use 'em' or any other unit, the line spacing is fixed to that value (unless you explicitly override it).
em in css is supposed to provide a size relative to the font-size... no? I mean that's what I use it for...
So 1em on a 20px font is 20px
therefore: if I change a 20px font to 30px, 1em = 30px if I change it to 180px, 1em = 180px
Sure, it's still just 1em (a fixed value), but what it translates to in terms of px, mm, in, etc is in relation to the font size...
Am I wrong? :)
What you want to use is a unit-less value.
https://developer.mozilla.org/en-US/docs/Web/CSS/line-heightOkay, so the REAL problem is inheritance conflicts associated with em. That's fine with me, then let's use unitless values instead. According to the links posted, under normal circumstances it does the same thing as em (acts as a multiplier to the font-size), but is not affected by inheritance. Fine with me. :)
-C
On Sun, 2016-11-13 at 14:43 +0000, C R wrote:
1.- Remove set default text format definition whith only click. Is hard to use well, give usualy bad results and most important text default styling is changed magicaly to the final user. I know it and be brong on tenxt editing several times in the same doc.
2.- Line height changes not work correctly if there is selected text, is hard to change baseline once the text is entered, finaly I become coping the text and pasting into a new text item
3.- If you change the size of a text, baseline is not updated and also become to "bug" 2
Okay, I work with a lot of text all the time. I've kinda accepted that it's a pain in the ass compared to a lot of other programs I've used in the past in a few ways, some of them highlighted by Jabier.
Here are my recommended fixes based on my own text-heavy workflows:
- Get rid of all concepts of a "default font", and replace with
"last used". Most often you just want to use the last font you were using before. It's much easier than trying to define a universal default, forgetting what the default you set is, and having to change a bunch of things around after you see it.
Replace that value with the value of the the last font used.
Fix ctrl+shift+v to paste the style correctly when a flowed text
box is selected, and make it possible to paste style between flowed and non-flowed text. (It's current broken).
- Use "em" as the default units for spacing between baselines: em
is based on the height of the font, and therefore provides a vector- like scaling of spaces between lines during font-size resizing- thus if you change the font-size, you can be sure the line-spacing is going to be the same visual spacing that you just painstakingly adjusted to fit the chosen font. The increment should be changed to a fractional amount of em (0.05) for proper granularity (though 0.1 increment would be okay for most purposes, imho) 1 em is too much of an increment.
If you do these things these problems *should* vanish, and you can remove that button from the text properties, and users can just copy/paste styles from headlines, paragraphs, etc, etc. without having to worry about default fonts.
The only exception to this is of course if Inkscape stores a default font value for the document. In which case, keep the button and load the default font only when the document is opened. This will provide the benefit of a default staring font, without requiring the user to continually sumble over it for the rest of the editing session.
If anyone wants to see workflow diagrams on these points let me know.
Thanks for your work on this, Jabier! -C
On Fri, Nov 11, 2016 at 2:39 PM, Jabier Arraiza <jabier.arraiza@...2893...> wrote:
Hi Sylvain. Reply inline
(1) When you click on the document with the text tool, and change text format before typing anything, default text format is changed accordingly. It shouldn’t.
But I’m testing the feature: if you change the format before typing, you can’t type anymore, you have to click again on the document, means creating a new text object. So the fix should be:
(1) If you change text format in the control bar with the text tool and no text object focused, it should only apply to the next text creation and should not be set as the default text format.
YES!
(2) Line height should only be changed for full lines: the control should be disabled/grayed when characters are selected.
Not, I think is best always working the same has or not has selected glyps and the changes apply to the whole text always.
(3) The baseline (I guess ‘vertical shift’) should be updated proportionally with text size changes.
Sure for % line heights, not sure about the others.
I can’t test (3), my controls (kerning, shift and rotation) are keeping disabled when text is focused, I don’t understand why.
All the best, Jabier.
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Maybe we can set default line height to unitless in prefs at close inkscape?
On Sun, 2016-11-13 at 21:30 +0000, C R wrote:
In fact, I'd go as far as to say that if the user sets the units to anything other than em or unitless, the spacing should probably stay the same... (as it does now). I mean explicitly setting the line height for something to mm for example, it might be useful to keep that line height no matter what the font size is. So say you're trying to get your flowed text to line up over a set of lines that are 20px apart. Setting the units to px, and changing the value to 20 would allow you to experiment with the font size without changing the baseline of the font (and thus keeping the letters all nice and lined up on those lines. The user can always switch to em or unitless (which I think is a useful default for most people), and changed in the special cases that need fixed line spacing of a particular measure.
In short:
Case 1 (Default): Unit set to unitless (I don't care what the exact measurement is, I just want it to look good, and be able to have the line spacing adjust with the font size)
Case 2 (User changes): Units set to a specific unit of measurement (mm, px, etc) - (I care what the units are because I've set them to something, and I want you to preserve the line height I set, because it's a fixed height, not based off font size)
So both use cases are handled.
-C
On Sun, Nov 13, 2016 at 9:18 PM, C R <cajhne@...400...> wrote:
"em" is NOT what you want if you want the line spacing to increase as you change font size. If you use 'em' or any other unit, the line spacing is fixed to that value (unless you explicitly override it).
em in css is supposed to provide a size relative to the font- size... no? I mean that's what I use it for...
So 1em on a 20px font is 20px
therefore: if I change a 20px font to 30px, 1em = 30px if I change it to 180px, 1em = 180px
Sure, it's still just 1em (a fixed value), but what it translates to in terms of px, mm, in, etc is in relation to the font size...
Am I wrong? :)
What you want to use is a unit-less value. https://developer.mozilla.org/en-US/docs/Web/CSS/line-hei ght
Okay, so the REAL problem is inheritance conflicts associated with em. That's fine with me, then let's use unitless values instead. According to the links posted, under normal circumstances it does the same thing as em (acts as a multiplier to the font-size), but is not affected by inheritance. Fine with me. :)
-C
On Sun, 2016-11-13 at 14:43 +0000, C R wrote:
1.- Remove set default text format definition whith only click. Is hard to use well, give usualy bad results and most important text default styling is changed magicaly to the final user. I know it and be brong on tenxt editing several times in the same doc.
2.- Line height changes not work correctly if there is selected text, is hard to change baseline once the text is entered, finaly I become coping the text and pasting into a new text item
3.- If you change the size of a text, baseline is not updated and also become to "bug" 2
Okay, I work with a lot of text all the time. I've kinda accepted that it's a pain in the ass compared to a lot of other programs I've used in the past in a few ways, some of them highlighted by Jabier.
Here are my recommended fixes based on my own text-heavy workflows:
- Get rid of all concepts of a "default font", and replace
with "last used". Most often you just want to use the last font you were using before. It's much easier than trying to define a universal default, forgetting what the default you set is, and having to change a bunch of things around after you see it.
- Replace that value with the value of the the last font
used.
- Fix ctrl+shift+v to paste the style correctly when a
flowed text box is selected, and make it possible to paste style between flowed and non-flowed text. (It's current broken).
- Use "em" as the default units for spacing between
baselines: em is based on the height of the font, and therefore provides a vector- like scaling of spaces between lines during font-size resizing- thus if you change the font-size, you can be sure the line-spacing is going to be the same visual spacing that you just painstakingly adjusted to fit the chosen font. The increment should be changed to a fractional amount of em (0.05) for proper granularity (though 0.1 increment would be okay for most purposes, imho) 1 em is too much of an increment.
If you do these things these problems *should* vanish, and you can remove that button from the text properties, and users can just copy/paste styles from headlines, paragraphs, etc, etc. without having to worry about default fonts.
The only exception to this is of course if Inkscape stores a default font value for the document. In which case, keep the button and load the default font only when the document is opened. This will provide the benefit of a default staring font, without requiring the user to continually sumble over it for the rest of the editing session.
If anyone wants to see workflow diagrams on these points let me know.
Thanks for your work on this, Jabier! -C
On Fri, Nov 11, 2016 at 2:39 PM, Jabier Arraiza <jabier.arraiza@...2893...> wrote:
Hi Sylvain. Reply inline > > (1) When you click on the document with the text tool, > and > change > text > format before typing anything, default text format is > changed > accordingly. It shouldn’t. > > But I’m testing the feature: if you change the format > before > typing, > you > can’t type anymore, you have to click again on the > document, > means > creating a new text object. So the fix should be: > > (1) If you change text format in the control bar with the > text > tool > and > no text object focused, it should only apply to the next > text > creation > and should not be set as the default text format.
YES!
> > > (2) Line height should only be changed for full lines: > the > control > should be disabled/grayed when characters are selected.
Not, I think is best always working the same has or not has selected glyps and the changes apply to the whole text always.
> > (3) The baseline (I guess ‘vertical shift’) should be > updated > proportionally with text size changes.
Sure for % line heights, not sure about the others.
> > I can’t test (3), my controls (kerning, shift and > rotation) are > keeping > disabled when text is focused, I don’t understand why.
All the best, Jabier.
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, Nov 13, 2016 at 9:36 PM, Jabiertxo Arraiza Cenoz <jabier.arraiza@...2893...> wrote:
Maybe we can set default line height to unitless in prefs at close inkscape?
Yep, that's what I recommend. and a 1.5 unitless multiplier value to start with, which correspond to the commonly used 1.5em line height in css for web pages. This would provide a good visual default for spacing of lines in paragraphs, and a reasonable beginning wrap-around value for headline type. If we could also change the unit increment to .05 or .1 (when you hit the up or down arrow to change the value, or use the mouse-wheel over the line-height field), that will be far more useful than integer increments, which are way too large. :)
In all my years as a designer, I may have once or twice had the need to set a fixed line height. Most of the time the size of the font (down to about 8pts for readability) and the line height are proportionate to eachother, and just need to visually look good.
But this way the user can have either, and it's not too much trouble either way. It will save a lot of needless messing around with line-height independently.
My 2p. -C
On Sun, 2016-11-13 at 21:30 +0000, C R wrote:
In fact, I'd go as far as to say that if the user sets the units to anything other than em or unitless, the spacing should probably stay the same... (as it does now). I mean explicitly setting the line height for something to mm for example, it might be useful to keep that line height no matter what the font size is. So say you're trying to get your flowed text to line up over a set of lines that are 20px apart. Setting the units to px, and changing the value to 20 would allow you to experiment with the font size without changing the baseline of the font (and thus keeping the letters all nice and lined up on those lines. The user can always switch to em or unitless (which I think is a useful default for most people), and changed in the special cases that need fixed line spacing of a particular measure.
In short:
Case 1 (Default): Unit set to unitless (I don't care what the exact measurement is, I just want it to look good, and be able to have the line spacing adjust with the font size)
Case 2 (User changes): Units set to a specific unit of measurement (mm, px, etc) - (I care what the units are because I've set them to something, and I want you to preserve the line height I set, because it's a fixed height, not based off font size)
So both use cases are handled.
-C
On Sun, Nov 13, 2016 at 9:18 PM, C R <cajhne@...400...> wrote:
"em" is NOT what you want if you want the line spacing to increase as you change font size. If you use 'em' or any other unit, the line spacing is fixed to that value (unless you explicitly override it).
em in css is supposed to provide a size relative to the font- size... no? I mean that's what I use it for...
So 1em on a 20px font is 20px
therefore: if I change a 20px font to 30px, 1em = 30px if I change it to 180px, 1em = 180px
Sure, it's still just 1em (a fixed value), but what it translates to in terms of px, mm, in, etc is in relation to the font size...
Am I wrong? :)
What you want to use is a unit-less value. https://developer.mozilla.org/en-US/docs/Web/CSS/line-hei ght
Okay, so the REAL problem is inheritance conflicts associated with em. That's fine with me, then let's use unitless values instead. According to the links posted, under normal circumstances it does the same thing as em (acts as a multiplier to the font-size), but is not affected by inheritance. Fine with me. :)
-C
On Sun, 2016-11-13 at 14:43 +0000, C R wrote:
1.- Remove set default text format definition whith only click. Is hard to use well, give usualy bad results and most important text default styling is changed magicaly to the final user. I know it and be brong on tenxt editing several times in the same doc.
2.- Line height changes not work correctly if there is selected text, is hard to change baseline once the text is entered, finaly I become coping the text and pasting into a new text item
3.- If you change the size of a text, baseline is not updated and also become to "bug" 2
Okay, I work with a lot of text all the time. I've kinda accepted that it's a pain in the ass compared to a lot of other programs I've used in the past in a few ways, some of them highlighted by Jabier.
Here are my recommended fixes based on my own text-heavy workflows:
- Get rid of all concepts of a "default font", and replace
with "last used". Most often you just want to use the last font you were using before. It's much easier than trying to define a universal default, forgetting what the default you set is, and having to change a bunch of things around after you see it.
- Replace that value with the value of the the last font
used.
- Fix ctrl+shift+v to paste the style correctly when a
flowed text box is selected, and make it possible to paste style between flowed and non-flowed text. (It's current broken).
- Use "em" as the default units for spacing between
baselines: em is based on the height of the font, and therefore provides a vector- like scaling of spaces between lines during font-size resizing- thus if you change the font-size, you can be sure the line-spacing is going to be the same visual spacing that you just painstakingly adjusted to fit the chosen font. The increment should be changed to a fractional amount of em (0.05) for proper granularity (though 0.1 increment would be okay for most purposes, imho) 1 em is too much of an increment.
If you do these things these problems *should* vanish, and you can remove that button from the text properties, and users can just copy/paste styles from headlines, paragraphs, etc, etc. without having to worry about default fonts.
The only exception to this is of course if Inkscape stores a default font value for the document. In which case, keep the button and load the default font only when the document is opened. This will provide the benefit of a default staring font, without requiring the user to continually sumble over it for the rest of the editing session.
If anyone wants to see workflow diagrams on these points let me know.
Thanks for your work on this, Jabier! -C
On Fri, Nov 11, 2016 at 2:39 PM, Jabier Arraiza <jabier.arraiza@...2893...> wrote: > > Hi Sylvain. > Reply inline > > > > (1) When you click on the document with the text tool, > > and > > change > > text > > format before typing anything, default text format is > > changed > > accordingly. It shouldn’t. > > > > But I’m testing the feature: if you change the format > > before > > typing, > > you > > can’t type anymore, you have to click again on the > > document, > > means > > creating a new text object. So the fix should be: > > > > (1) If you change text format in the control bar with the > > text > > tool > > and > > no text object focused, it should only apply to the next > > text > > creation > > and should not be set as the default text format. > > YES! > > > > > > > > (2) Line height should only be changed for full lines: > > the > > control > > should be disabled/grayed when characters are selected. > > Not, I think is best always working the same has or not has > selected > glyps and the changes apply to the whole text always. > > > > > (3) The baseline (I guess ‘vertical shift’) should be > > updated > > proportionally with text size changes. > > Sure for % line heights, not sure about the others. > > > > > I can’t test (3), my controls (kerning, shift and > > rotation) are > > keeping > > disabled when text is focused, I don’t understand why. > > All the best, Jabier. > > > --------------------------------------------------------- > -------- > ------------- > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer > platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi again.
First of all Text tool has a option in prefs to set to last used style :), I dont know it, sorry for the noise.
Second I find a bug in 0.92.x and trunk with unitless line heights. The problem is: Select unitless value, for example 1.0, start typyng and units become 10000% also on return the text go very far away making unitless unusable currently in my computer.
Cheers, Jabier.
On Sun, 2016-11-13 at 22:36 +0100, Jabiertxo Arraiza Cenoz wrote:
Maybe we can set default line height to unitless in prefs at close inkscape?
On Sun, 2016-11-13 at 21:30 +0000, C R wrote:
In fact, I'd go as far as to say that if the user sets the units to anything other than em or unitless, the spacing should probably stay the same... (as it does now). I mean explicitly setting the line height for something to mm for example, it might be useful to keep that line height no matter what the font size is. So say you're trying to get your flowed text to line up over a set of lines that are 20px apart. Setting the units to px, and changing the value to 20 would allow you to experiment with the font size without changing the baseline of the font (and thus keeping the letters all nice and lined up on those lines. The user can always switch to em or unitless (which I think is a useful default for most people), and changed in the special cases that need fixed line spacing of a particular measure.
In short:
Case 1 (Default): Unit set to unitless (I don't care what the exact measurement is, I just want it to look good, and be able to have the line spacing adjust with the font size)
Case 2 (User changes): Units set to a specific unit of measurement (mm, px, etc) - (I care what the units are because I've set them to something, and I want you to preserve the line height I set, because it's a fixed height, not based off font size)
So both use cases are handled.
-C
On Sun, Nov 13, 2016 at 9:18 PM, C R <cajhne@...400...> wrote:
"em" is NOT what you want if you want the line spacing to increase as you change font size. If you use 'em' or any other unit, the line spacing is fixed to that value (unless you explicitly override it).
em in css is supposed to provide a size relative to the font- size... no? I mean that's what I use it for...
So 1em on a 20px font is 20px
therefore: if I change a 20px font to 30px, 1em = 30px if I change it to 180px, 1em = 180px
Sure, it's still just 1em (a fixed value), but what it translates to in terms of px, mm, in, etc is in relation to the font size...
Am I wrong? :)
What you want to use is a unit-less value. https://developer.mozilla.org/en-US/docs/Web/CSS/line-h ei ght
Okay, so the REAL problem is inheritance conflicts associated with em. That's fine with me, then let's use unitless values instead. According to the links posted, under normal circumstances it does the same thing as em (acts as a multiplier to the font-size), but is not affected by inheritance. Fine with me. :)
-C
On Sun, 2016-11-13 at 14:43 +0000, C R wrote:
1.- Remove set default text format definition whith only click. Is hard to use well, give usualy bad results and most important text default styling is changed magicaly to the final user. I know it and be brong on tenxt editing several times in the same doc.
2.- Line height changes not work correctly if there is selected text, is hard to change baseline once the text is entered, finaly I become coping the text and pasting into a new text item
3.- If you change the size of a text, baseline is not updated and also become to "bug" 2
Okay, I work with a lot of text all the time. I've kinda accepted that it's a pain in the ass compared to a lot of other programs I've used in the past in a few ways, some of them highlighted by Jabier.
Here are my recommended fixes based on my own text-heavy workflows:
- Get rid of all concepts of a "default font", and replace
with "last used". Most often you just want to use the last font you were using before. It's much easier than trying to define a universal default, forgetting what the default you set is, and having to change a bunch of things around after you see it.
- Replace that value with the value of the the last font
used.
- Fix ctrl+shift+v to paste the style correctly when a
flowed text box is selected, and make it possible to paste style between flowed and non-flowed text. (It's current broken).
- Use "em" as the default units for spacing between
baselines: em is based on the height of the font, and therefore provides a vector- like scaling of spaces between lines during font-size resizing- thus if you change the font-size, you can be sure the line-spacing is going to be the same visual spacing that you just painstakingly adjusted to fit the chosen font. The increment should be changed to a fractional amount of em (0.05) for proper granularity (though 0.1 increment would be okay for most purposes, imho) 1 em is too much of an increment.
If you do these things these problems *should* vanish, and you can remove that button from the text properties, and users can just copy/paste styles from headlines, paragraphs, etc, etc. without having to worry about default fonts.
The only exception to this is of course if Inkscape stores a default font value for the document. In which case, keep the button and load the default font only when the document is opened. This will provide the benefit of a default staring font, without requiring the user to continually sumble over it for the rest of the editing session.
If anyone wants to see workflow diagrams on these points let me know.
Thanks for your work on this, Jabier! -C
On Fri, Nov 11, 2016 at 2:39 PM, Jabier Arraiza <jabier.arraiza@...2893...> wrote: > > Hi Sylvain. > Reply inline > > > > (1) When you click on the document with the text tool, > > and > > change > > text > > format before typing anything, default text format is > > changed > > accordingly. It shouldn’t. > > > > But I’m testing the feature: if you change the format > > before > > typing, > > you > > can’t type anymore, you have to click again on the > > document, > > means > > creating a new text object. So the fix should be: > > > > (1) If you change text format in the control bar with > > the > > text > > tool > > and > > no text object focused, it should only apply to the > > next > > text > > creation > > and should not be set as the default text format. > > YES! > > > > > > > > (2) Line height should only be changed for full lines: > > the > > control > > should be disabled/grayed when characters are selected. > > Not, I think is best always working the same has or not > has > selected > glyps and the changes apply to the whole text always. > > > > > (3) The baseline (I guess ‘vertical shift’) should be > > updated > > proportionally with text size changes. > > Sure for % line heights, not sure about the others. > > > > > I can’t test (3), my controls (kerning, shift and > > rotation) are > > keeping > > disabled when text is focused, I don’t understand why. > > All the best, Jabier. > > > --------------------------------------------------------- > -------- > ------------- > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer > platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-dev > el
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
First of all Text tool has a option in prefs to set to last used style :), I dont know it, sorry for the noise.
It should be set to that by default, imho. Sure, leave it so the user can change it, but I think it will prove to become the dustiest of the user dust-laden user prefs so far. :)
Second I find a bug in 0.92.x and trunk with unitless line heights. The problem is: Select unitless value, for example 1.0, start typyng and units become 10000% also on return the text go very far away making unitless unusable currently in my computer.
I can't reproduce that problem... can you provide a file? Seems to be working like I's expect em to work. Also note that any value above 2 is probably going to be too large of a gap.
-C
On Sun, 2016-11-13 at 22:36 +0100, Jabiertxo Arraiza Cenoz wrote:
Maybe we can set default line height to unitless in prefs at close inkscape?
On Sun, 2016-11-13 at 21:30 +0000, C R wrote:
In fact, I'd go as far as to say that if the user sets the units to anything other than em or unitless, the spacing should probably stay the same... (as it does now). I mean explicitly setting the line height for something to mm for example, it might be useful to keep that line height no matter what the font size is. So say you're trying to get your flowed text to line up over a set of lines that are 20px apart. Setting the units to px, and changing the value to 20 would allow you to experiment with the font size without changing the baseline of the font (and thus keeping the letters all nice and lined up on those lines. The user can always switch to em or unitless (which I think is a useful default for most people), and changed in the special cases that need fixed line spacing of a particular measure.
In short:
Case 1 (Default): Unit set to unitless (I don't care what the exact measurement is, I just want it to look good, and be able to have the line spacing adjust with the font size)
Case 2 (User changes): Units set to a specific unit of measurement (mm, px, etc) - (I care what the units are because I've set them to something, and I want you to preserve the line height I set, because it's a fixed height, not based off font size)
So both use cases are handled.
-C
On Sun, Nov 13, 2016 at 9:18 PM, C R <cajhne@...400...> wrote:
"em" is NOT what you want if you want the line spacing to increase as you change font size. If you use 'em' or any other unit, the line spacing is fixed to that value (unless you explicitly override it).
em in css is supposed to provide a size relative to the font- size... no? I mean that's what I use it for...
So 1em on a 20px font is 20px
therefore: if I change a 20px font to 30px, 1em = 30px if I change it to 180px, 1em = 180px
Sure, it's still just 1em (a fixed value), but what it translates to in terms of px, mm, in, etc is in relation to the font size...
Am I wrong? :)
What you want to use is a unit-less value. https://developer.mozilla.org/en-US/docs/Web/CSS/line-h ei ght
Okay, so the REAL problem is inheritance conflicts associated with em. That's fine with me, then let's use unitless values instead. According to the links posted, under normal circumstances it does the same thing as em (acts as a multiplier to the font-size), but is not affected by inheritance. Fine with me. :)
-C
On Sun, 2016-11-13 at 14:43 +0000, C R wrote: > > 1.- Remove set default text format definition whith only > click. > Is hard to use well, give usualy bad results and most > important > text > default styling is changed magicaly to the final user. I > know > it > and > be > brong on tenxt editing several times in the same doc. > > 2.- Line height changes not work correctly if there is > selected > text, > is hard to change baseline once the text is entered, finaly > I > become > coping the text and pasting into a new text item > > 3.- If you change the size of a text, baseline is not > updated > and > also > become to "bug" 2 > > > Okay, I work with a lot of text all the time. I've kinda > accepted > that > it's a pain in the ass compared to a lot of other programs > I've > used > in the past in a few ways, some of them highlighted by > Jabier. > > Here are my recommended fixes based on my own text-heavy > workflows: > > > 1. Get rid of all concepts of a "default font", and replace > with > "last > used". Most often you just want to use the last font you > were > using > before. It's much easier than trying to define a universal > default, > forgetting what the default you set is, and having to > change > a > bunch > of things around after you see it. > > 2. Replace that value with the value of the the last font > used. > > 3. Fix ctrl+shift+v to paste the style correctly when a > flowed text > box is selected, and make it possible to paste style > between > flowed > and non-flowed text. (It's current broken). > > 4. Use "em" as the default units for spacing between > baselines: em > is > based on the height of the font, and therefore provides a > vector- > like > scaling of spaces between lines during font-size resizing- > thus if > you > change the font-size, you can be sure the line-spacing is > going to > be > the same visual spacing that you just painstakingly > adjusted > to fit > the chosen font. The increment should be changed to a > fractional > amount of em (0.05) for proper granularity (though 0.1 > increment > would > be okay for most purposes, imho) 1 em is too much of an > increment. > > If you do these things these problems *should* vanish, and > you can > remove that button from the text properties, and users can > just > copy/paste styles from headlines, paragraphs, etc, etc. > without > having > to worry about default fonts. > > The only exception to this is of course if Inkscape stores > a > default > font value for the document. In which case, keep the button > and > load > the default font only when the document is opened. This > will > provide > the benefit of a default staring font, without requiring > the > user > to > continually sumble over it for the rest of the editing > session. > > If anyone wants to see workflow diagrams on these points > let > me > know. > > Thanks for your work on this, Jabier! > -C > > > On Fri, Nov 11, 2016 at 2:39 PM, Jabier Arraiza > <jabier.arraiza@...2893...> wrote: > > > > Hi Sylvain. > > Reply inline > > > > > > (1) When you click on the document with the text tool, > > > and > > > change > > > text > > > format before typing anything, default text format is > > > changed > > > accordingly. It shouldn’t. > > > > > > But I’m testing the feature: if you change the format > > > before > > > typing, > > > you > > > can’t type anymore, you have to click again on the > > > document, > > > means > > > creating a new text object. So the fix should be: > > > > > > (1) If you change text format in the control bar with > > > the > > > text > > > tool > > > and > > > no text object focused, it should only apply to the > > > next > > > text > > > creation > > > and should not be set as the default text format. > > > > YES! > > > > > > > > > > > > > (2) Line height should only be changed for full lines: > > > the > > > control > > > should be disabled/grayed when characters are selected. > > > > Not, I think is best always working the same has or not > > has > > selected > > glyps and the changes apply to the whole text always. > > > > > > > > (3) The baseline (I guess ‘vertical shift’) should be > > > updated > > > proportionally with text size changes. > > > > Sure for % line heights, not sure about the others. > > > > > > > > I can’t test (3), my controls (kerning, shift and > > > rotation) are > > > keeping > > > disabled when text is focused, I don’t understand why. > > > > All the best, Jabier. > > > > > > --------------------------------------------------------- > > -------- > > ------------- > > Developer Access Program for Intel Xeon Phi Processors > > Access to Intel Xeon Phi processor-based developer > > platforms. > > With one year of Intel Parallel Studio XE. > > Training and support from Colfax. > > Order your platform today. http://sdm.link/xeonphi > > _______________________________________________ > > Inkscape-devel mailing list > > Inkscape-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/inkscape-dev > > el
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi CR. On Mon, 2016-11-14 at 17:15 +0000, C R wrote:
First of all Text tool has a option in prefs to set to last used style :), I dont know it, sorry for the noise.
It should be set to that by default, imho. Sure, leave it so the user can change it, but I think it will prove to become the dustiest of the user dust-laden user prefs so far. :)
Is a small change I can do to preferences-skeleton file, now waiting to commit to see more feedback. if nombody stop it I commit it soon into 0.92.x and trunk. The changes are: Last used style in text as default and line-height at first launch to 1.5-
Second I find a bug in 0.92.x and trunk with unitless line heights. The problem is: Select unitless value, for example 1.0, start typyng and units become 10000% also on return the text go very far away making unitless unusable currently in my computer.
I can't reproduce that problem... can you provide a file? Seems to be working like I's expect em to work. Also note that any value above 2 is probably going to be too large of a gap.
Is a problem with my OLD prefs, try with clean ones and no problem :)!!!
Cheers, Jabier.
Thanks Jabier! This is going to save me so much time!
-C
On Mon, Nov 14, 2016 at 5:43 PM, Jabiertxo Arraiza Cenoz <jabier.arraiza@...2893...> wrote:
Hi CR. On Mon, 2016-11-14 at 17:15 +0000, C R wrote:
First of all Text tool has a option in prefs to set to last used style :), I dont know it, sorry for the noise.
It should be set to that by default, imho. Sure, leave it so the user can change it, but I think it will prove to become the dustiest of the user dust-laden user prefs so far. :)
Is a small change I can do to preferences-skeleton file, now waiting to commit to see more feedback. if nombody stop it I commit it soon into 0.92.x and trunk. The changes are: Last used style in text as default and line-height at first launch to 1.5-
Second I find a bug in 0.92.x and trunk with unitless line heights. The problem is: Select unitless value, for example 1.0, start typyng and units become 10000% also on return the text go very far away making unitless unusable currently in my computer.
I can't reproduce that problem... can you provide a file? Seems to be working like I's expect em to work. Also note that any value above 2 is probably going to be too large of a gap.
Is a problem with my OLD prefs, try with clean ones and no problem :)!!!
Cheers, Jabier.
That's fine, Jabier. I use Inkscape all the time, and make at least a few new files inkscape svg files every day. One less thing to stumble over doesn't seem like much, but in the long run, it really adds up.
Thanks again. :)
-C
On Mon, Nov 14, 2016 at 6:38 PM, Jabiertxo Arraiza Cenoz <jabier.arraiza@...2893...> wrote:
Hi CR On Mon, 2016-11-14 at 18:34 +0000, C R wrote:
Thanks Jabier! This is going to save me so much time!
You are welcome but the change I propose only affect to first launch/new prefs file runs
Cheers, Jabier.
CR: Global first launch, not each time you run the app :(
Cheers, Jabier.
On Mon, 2016-11-14 at 19:25 +0000, C R wrote:
That's fine, Jabier. I use Inkscape all the time, and make at least a few new files inkscape svg files every day. One less thing to stumble over doesn't seem like much, but in the long run, it really adds up.
Thanks again. :)
-C
On Mon, Nov 14, 2016 at 6:38 PM, Jabiertxo Arraiza Cenoz <jabier.arraiza@...2893...> wrote:
Hi CR On Mon, 2016-11-14 at 18:34 +0000, C R wrote:
Thanks Jabier! This is going to save me so much time!
You are welcome but the change I propose only affect to first launch/new prefs file runs
Cheers, Jabier.
Well it should only have to set the pref once, right? Sorry, maybe I don't get it.
Will test and advise after It's changed. -C
On Tue, Nov 15, 2016 at 8:46 AM, Jabier Arraiza <jabier.arraiza@...2893...> wrote:
CR: Global first launch, not each time you run the app :(
Cheers, Jabier.
On Mon, 2016-11-14 at 19:25 +0000, C R wrote:
That's fine, Jabier. I use Inkscape all the time, and make at least a few new files inkscape svg files every day. One less thing to stumble over doesn't seem like much, but in the long run, it really adds up.
Thanks again. :)
-C
On Mon, Nov 14, 2016 at 6:38 PM, Jabiertxo Arraiza Cenoz <jabier.arraiza@...2893...> wrote:
Hi CR On Mon, 2016-11-14 at 18:34 +0000, C R wrote:
Thanks Jabier! This is going to save me so much time!
You are welcome but the change I propose only affect to first launch/new prefs file runs
Cheers, Jabier.
participants (5)
-
C R -
Jabier Arraiza -
Jabiertxo Arraiza Cenoz -
Sylvain Chiron -
Tavmjong Bah