|
|
Ultimately, it would be nice to remove Small caps, super- and subscript from the global document preferences, and add them to the paragraph style as well. +-- Bold face -----------------------------------+ | [ ] Use this font: ___________________ | | [ ] | | | +-- Italics -------------------------------------+ | [ ] Use this font: ___________________ | | [ ] Slant ____ % | | | +-- Small Caps ----------------------------------+ | [ ] Use this font: ___________________ | | [ ] Scale to _____ % of font size | | | +-- Superscript ---------------------------------+ | [ ] Use this font: ___________________ | | Displacement ____ % Scaling ____ % | | | +-- Subscript -----------------------------------+ | [ ] Use this font: ___________________ | | Displacement ____ % Scaling ____ % | | | +------------------------------------------------+ Now in each case, you can pick a font that is especially designed as a boldface, cursive, etc., or to artificially tweak the font you're using to become boldfaced, italics, small caps, etc. |
|
|
I like this idea. It has the merit of not letting the user just select "italic" but to attribute a specific font "I could add: "that will print" to the "italic" option. This will prevent users from very common errors with fonts (using italic or bold that don't exist and thus will never print in bold or italic). It's also easily understandable and intuitive. Attached to a specific style, it automates the process of formatting text with more precision than lots of other programs... I can't think right now of a drawback to this idea. On the superscript/subscript issue, I filed a bug (feature) on that - bug # 498 - and again, cannot agree more with packetbell. Just a little add-on : for superscript and subscript as well as small caps, wouldn't it be even more intuitive to also have a check box "Keep same font" then the scaling and offset settings. Thinking it over, my only reserve is I am not too keen about a "slant" option for italic. ;-) edited on: 04-09-18 15:25 edited on: 04-09-18 15:27 |
|
|
>>> Thinking it over, my only reserve is I am not too keen about a °slant° option for italic. ;-) Agreed (who would be?). But, the slant option is just that, an option. In each case, you can pick a font (from the same family) that is especially designed as a boldface, cursive, etc., *or* you can artificially tweak the font you're using to become boldfaced, italics, small caps, etc. This would also make it very easy to use a *completely different font* for boldface, small caps, etc. CoolFX! >>> Just a little add-on : for superscript and subscript as well as small caps, wouldn’t it be even more intuitive to also have a check box “Keep same font“ then the scaling and offset settings. Well, in the example above, *not* selecting a different font will keep the same font. But I agree, it would be more intuitive to add the checkbox, or for each style to remove the "[X] Use this font: " checkbox and make it a drop-down instead, with two options: "Use Font from Regular Style" "Select Custom Font..." edited on: 04-09-22 23:40 |
|
|
>>>> [...] the slant option is just that, an option. Yes. You're right, an option is an option. It's up to the user to slant the text or not. So, agree! >>> This would also make it very easy to use a *completely different font* for boldface, small caps, etc. CoolFX! Exact! This way, we're even getting closer to the approach of "emphasis" instead of "italic", which makes more sense, imo. I wish the feature was already implemented! |
|
|
I have an idea for an alternative approach to the boldface/italic issue: How about globally accessible "character styles", with some options which can be *relative* to the paragraph style in which the text is embedded? (This would need to be combined with grouping of fonts in order to work properly for boldface and italics.) So for example you could define a "bold" character style, which would have "font" set to "the same as the paragraph style, but use the bold version". If no bold version exists for a particular font, the application of the style should not do anything. Pros: * The user wouldn't have to individually define bold/italic settings for each paragraph style - the bold/italic style would adapt to each paragraph style automatically * This is more general. The user wouldn't be limited to just bold and italic character formatting - one could define a variety of styles, for example a monospace font style for formatting all urls, etc. Cons: * Font grouping would also have to be implemented, so that Scribus understands what "use the bold version" means * If the user doesn't select bold and italic fonts explicitly, he may not notice when they don't exist and so won't be applied I'm not sure which approach would be better. |
|
|
All of this is planned... |
|
|
I'd argue that this particular need would be addressed by character styles. |
|
|
Both font grouping and character styles will be done. |
|
|
>Agreed (who would be?). But, the slant option is just that, an option. In each >case, you can pick a font (from the same family) that is especially designed as a >boldface, cursive, etc., Great.. >*or* you can artificially tweak the font you're using to >become boldfaced, >italics, small caps, etc. False bold and/or italics are a _very_ bad idea in DTP. This is one of the fundamental flaws in some DTP apps which can cause no end of issues downline. While you can get away with it *sometimes*, this at some point will bite you back. That can be expensive to an end user and ruin the reputation of an application. I _will_ most certainly resist any attempt to have false bolds/italics in PDF/PS output. Ask anyone knowlegeable about pre-press and get their reaction..Don't be surprised to hear lots of swearing ;-) Super/sub script/small caps is mostly an issue of scaling, tho certain OTF fonts do have true small caps. We might see more advanced OTF goodies in 1.3/1.4 |
|
|
I'm with Peter on artificial. They're just evil for DTP. They may seem attractive, but trust me you'll regret it later. You'll get type that doesn't look as good, and risk print problems that can be very expensive and embarrasing, especially if they're only discovered when you get your new 10,000 copy run of pamphlets back... One of the (many) reasons printers hate MS Word and people who try to use it for DTP is artificial styles. IIRC in Word they do great things like vary version to version, or change slightly if you have a different variant of the font, etc. Not fun. Artificial styles *might* be OK if they were only sent to output formats as vectors. Even so, IMO they're just a really bad idea. |
|
|
Some thoughts on this issue: 1) In general, I like the idea of substyles, and Louis' thoughts on an "emphasis" style exactly match my thoughts. It would be extremely useful to easily apply a predefined (in a sub style) "emphasis" in a paragraph. 2) As for packetbell's suggestions in his first post, I have some objections. Usability recently came up on the list as an important topic. IMHO, this would add a lot of complexity to the UI. Moreover, it encourages unexperienced users to make mistakes such as using lots of different fonts. I wouldn't even consider using Louis' suggestion for checkboxes. There really should be a barrier to prevent people from applying typographical "tutti-frutti". If needed, it can be done manually in the story editor (which would be a useful barrier for people who think that a document is only well designed if you have at least 20 different fonts in it). 3) In some cases, different fonts for different purposes might be needed, but that's what character styles are for. Pls. keep it separate from subsets of paragraph styles 4) I wouldn't even think about fake italics/bolds. Even if they were turned to outline, the result would be ugly. If scribus wants to be recognised as a serious DTP app, this should be a taboo. In case a font has no bolds and you need them, look for another one! |
|
|
>>>> 2. [...] this would add a lot of complexity to the UI. Moreover, it encourages unexperienced users to make mistakes such as using lots of different fonts. [...] Disagree. The idea here is in fact to avoid these mistakes by forcing users to use fonts that exist, and only font that exist. If an italic face exists for a specific font, Scribus could propose it as the default. So most of the time, users wouldn't even have to bother about that dialog. *But* the option being there, this would give Scribus a real punch in text formatting. On the usability side, it is also clear to me that this feature would be considered as "advanced" and I can't think of a better way of handling so many situations where "mapping" fonts is really what's needed. So, I stand by my first thoughts. >>>>3) In some cases, different fonts for different purposes might be needed, but that's what character styles are for. Pls. keep it separate from subsets of paragraph styles Depends. With the advent of OpenType, and when all the features or this font format will be properly implemented into Scribus, this might prove to be irrelevant on the long run. In the mean time, there still is a need for "Expert" fonts as Adobe puts it, for specific ligatures, numbers and small caps, (to name a few). In that case, while the "check box" idea might not be the best way of doing this, there is a need to actually tell Scribus what font to use, in what situation. For instance, if you define small caps as "this Expert font" instead of a 75% scaling of any regular font, then there is a need to specify that font. It's a matter of efficiency, productivity and of avoiding errors. On the opposite, if all you want is to scale the regular font, then the check box tells Scribus to basically behave as it does right now. So, while users could still use "styles" (this word can lead to misunderstanding because it is the same as in paragraph styles, which is not what I refer to at the moment) to apply small caps, super/sub scripts, italic, etc, we would have control over what's going on under the hood. Scaling fonts distort the fonts. While it is a necessity in many situations, you can hardly rely on this stratageme to achieve high quality typography in many aspects. (Hope you get the idea. I aknowledge this could be developped further more.) >>>>4) I wouldn't even think about fake italics/bolds. Even if they were turned to outline, the result would be ugly. If scribus wants to be recognised as a serious DTP app, this should be a taboo. In case a font has no bolds and you need them, look for another one! If I am not mistaken, we *all* strongly agree on that ! |
|
2005-07-24 18:31
|
1_new_style.png (16,211 bytes) |
|
2005-07-24 18:31
|
2_creating_substyle_1.png (22,653 bytes) |
|
2005-07-24 18:32
|
3_creating_substyle_2.png (19,091 bytes) |
|
2005-07-24 18:33
|
4_modify_substyle.png (33,619 bytes) |
|
2005-07-24 18:33
|
5_style_hierarchy.png (22,867 bytes) |
|
2005-07-24 18:33
|
6_change_master_style.png (38,392 bytes) |
|
2005-07-24 18:33
|
7_automatically_changed_substyle.png (31,548 bytes) |
|
|
Maybe the issues discussed here can really be solved by using sharacter styles as in OO.o. To explain what I mean, I have added some screen shots. Here is what I did: First, I created a new style called "standard paragraph", based on "Default" (1_new_style.png). After having adjusted the settings, I created a second style called "emphasis", based on "standard paragraph" (2_creating_substyle_1.png, 3_creating_substyle_2.png). Since I needed the style for emphasised text, I changed the font face to "italic" (4_modify_substyle.png). If we now look at the stylist in the hierarchical view, we can identify "emphasis" as a sub style of "standard paragraph" (5_style_hierarchy.png). If I change the font in the master style (6_change_master_style.png), we can see the advantages of the approach since the font has also changed in the sub style (7_automatically_changed_substyle.png). Something like OO.o's stylist including hierarchical, inherited styles would come in handy for many formatting situations. It doesnt prevent the use of different fonts in sub styles, but by default they inherit settings from the master. I wonder if packetbell and Louis like the idea. Feedback welcome (see also http://bugs.scribus.net/view.php?id=1322) |
|
|
One thing I forgot to mention: My proposal only dealt with charcter styles. So problem of *paragraph* sub styles isn't solved. Maybe it should be possible to use a character style hierarchy in a para style? |
|
|
Hi Christoph, I understand what you're saying, but unless I miss something, isnt'it exactly what packetbell's idea is all about ? Plus, it adds a font mapping option that takes care of some specific issues such as described in the former posts of this thread. One thing I must say at this point is if we're going to avoid 'italic style' at all cost (and my understanding so far is this is exactly what we want) and use instead the real italic face of any given font, then the way OO.o handles this is misleading, imo. Besides, as a very personnal point of view, I also must say this kind of never ending dialog boxes with so many tabs is confusing. And on top, we are missing lots of font attributes such as super/sub scripts and small caps. I prefer by far the actual "Paragraph Style" dialog of Scribus, although it could benefit from small ameliorations. OO.o styler is a close cousin to MSWord in my view. This is not what I expect to see in Scribus (unless we all find this would be the only way to achieve a tight workflow using both program — I'm always ready to be proved wrong!). What I'd like to see there though, is keypad short cuts combinations for paragraph style. That's the only way we're going to avoid mouse clicks (round trips from selected text to the styler is all but productive). Basically, the movement is : use arrows on the keyboard to put your cursor on the paragraph to be formatted, and hit the appropriate key of the keypad to format. Then, arrow again to the next occurence. Or else, select entire parts... and hit the keypad. You get the idea. If the text is not already properly formatted in the Word Processor, this is a very efficient and fast way of formatting any text. Besides that, the fastest way being to format a database on the fly with pre-defined styles. Back to our issue, what I like most in packetbell's idea is the mapping possibilities, from "style" to "font", something that doesn't exist in other program, afaik. Adding to that the possibility to map styles themselves, we'd be all set for serious text formatting. :) |
|
|
Hi Louis, I'll work my way back from the end of your post to the beginning, because I think the crucial point is in your last sentence. ;) >>>Back to our issue, what I like most in packetbell's idea is the mapping possibilities, from "style" to "font", something that doesn't exist in other program, afaik. Adding to that the possibility to map styles themselves, we'd be all set for serious text formatting. :) My proposal is, to some extent, an extention to packetbell's ideas, and it's also a more general approach. If I understood packetbell, he wants to define several styles for "bold", "italic" etc. in the paragraph style dialog. You seem to like the idea, because keyboard shortcuts (like Ctrl + B for bold) could be easily used and would produce the desired result. My vote is for enabling the import of user defined character styles/style sets into paragraph styles. That way I can create styles like "emphasised", "strongly emphasised", "author" etc. I would be more flexible with that, because I could create style sets based on their content or their typographic function. The mapping of fonts would happen in the character style. It also has the advantage that I can apply the style set to many paragraph styles. Imagine three similar paragraph styles: "first paragraph", "standard paragraph", "initials". If you use packetbell's approach you would have to change the settings for each style (of course, you can duplicate a style and afterwards tweak it, and sooner or later, paragraph styles can also be inherited, but using character style sets still provides more flexibility, IMHO). >>>What I'd like to see there though, is keypad short cuts combinations for paragraph style. That's the only way we're going to avoid mouse clicks (round trips from selected text to the styler is all but productive). Basically, the movement is : use arrows on the keyboard to put your cursor on the paragraph to be formatted, and hit the appropriate key of the keypad to format. Then, arrow again to the next occurence. Or else, select entire parts... and hit the keypad. You get the idea. If the text is not already properly formatted in the Word Processor, this is a very efficient and fast way of formatting any text. Besides that, the fastest way being to format a database on the fly with pre-defined styles. That's still possible with my suggestion: move cursor to paragraph --> shortcut for paragraph style. With a paragraph style applied, select a word --> shortcut for whatever character style is available (e.g. Ctr + Alt + E) for emphasis. >>>One thing I must say at this point is if we're going to avoid 'italic style' at all cost (and my understanding so far is this is exactly what we want) and use instead the real italic face of any given font, then the way OO.o handles this is misleading, imo. Besides, as a very personnal point of view, I also must say this kind of never ending dialog boxes with so many tabs is confusing. And on top, we are missing lots of font attributes such as super/sub scripts and small caps. I prefer by far the actual "Paragraph Style" dialog of Scribus, although it could benefit from small ameliorations. You are talking about the limitations of a word processor. In scribus this wouldn't be possible. Scribus 1.3 already offers alternative faces of a font in the properties box. And, yes, scribus' style dialog is much better. I used OO.o to demonstrate the general principle (charcter styles). :) |
|
|
Hi Christoph, You definitely got a good point. If I summarize correctly, "bold" or "italic" are so general they could apply to just any paragraph style without distinction, then it could prove to be hardly usable to simply map "bold" or "italic" to a specific font without firstly determining a parent paragraph style (if I get your idea right). We're back to a character style and paragraph styles issue. I'd like to hear packetbell on this, and others! On the keyboard shortcuts, please note I refer to the keypad (as Quark and InDesign do). |
|
|
Hi Louis, >>>If I summarize correctly, "bold" or "italic" are so general they could apply to just any paragraph style without distinction, then it could prove to be hardly usable to simply map "bold" or "italic" to a specific font without firstly determining a parent paragraph style (if I get your idea right). We're back to a character style and paragraph styles issue. Depends. I'd say if you want to apply a key*board* shortcut like Ctrl+B and get the right font, I don't see any other way than defining and applying a paragraph style first. You have to do this with packetbell's approach as well, by the way. The paragraph style will determine the appropriate/desired font from the included character style (in this case bold). But one could of course have it both ways by assigning a key*pad* shortcut to a character style (in the style dialog). Then move your cursor to a word, select, and press Alt + numerical value in the keypad. |
|
|
The paragraph style is compulsory. Should always be, in my view. Keyboard and keypad : there is no difference here. A shortcut for a stylesheet can be applied from any number on the keypad. It has to be simple. Basically, the first 10 stylesheets can be applied with only one keystroke, from 0 to 9. (Here ID falls short of Quark because you're not allowed to use the keypad numbers alone as a stylesheet shortcut—sadly) Then, you can have any combination of Option+Keypad and Command+Keypad and Shift+Keypad. That give 40 possibilities altogether. Far over the most demanding situation. |
|
|
Hi Louis, >>> The paragraph style is compulsory. Should always be, in my view. Fully agreed, but if you have separate character styles, you can always access them via keypad operations ... just in case. >>>Keyboard and keypad : there is no difference here. From the usability point of view, there might be a difference: Some people are used to keyboard shortcuts, some to keypad shortcuts, most to both. Keyboard shortcuts can be more intuitive, because the letter can indicate the function (Ctrl + B = bold). We also have to think about users who prefer the context menu. That's why I came up with OO's stylist, since it can (indirectly) be accessed through OO.o's context menu (scribus would need something better, of course). |
|
|
Context menu and key(board/pad) shortcuts are not mutually exclusive. :) Like for any other other menu, shortcuts are shortcuts. The long way still exists. Sorry to be so Quark used but I do think keypad shortcuts are far better (faster) from any other keyboard shortcut for applying stylesheets (not 'style' like bold or italic). My argument is it needs only 1 keystroke for the first 10 stylesheets. I can't think of something simpler. Years of formatting, when every hour (minutes!) counts, proves this to work in real life production. Users in need of context menus for applying stylesheets have not been under real fire. This is frankly said, no hard feelings at all. The only thing that beats the keyboard at formating is formating automatically from a database. The mouse and eye can't simply match the fastness, efficiency and accuracy of trained personnel's fingers on a keypad. :) |
|
|
Hi Louis, >>> Context menu and key(board/pad) shortcuts are not mutually exclusive. :) Like for any other other menu, shortcuts are shortcuts. The long way still exists. That's what I tried to express (not XPress ;) ) in my previous comment. Layout software is not only used by professional studios, but also in offices with a lower level of user experience (read: mouse based operating mode). >>>Sorry to be so Quark used Why? Most of the industry is. It's always worth taking note of the majority of users! >>>but I do think keypad shortcuts are far better (faster) from any other keyboard shortcut for applying stylesheets (not 'style' like bold or italic). My argument is it needs only 1 keystroke for the first 10 stylesheets. No disagreement, but keep in mind that the issue discussed here has consequences for the file format! >>>I can't think of something simpler. Years of formatting, when every hour (minutes!) counts, proves this to work in real life production. Users in need of context menus for applying stylesheets have not been under real fire. Certainly for experienced users. But also keep in mind the less experienced and those who don't need to work "industrial". >>>The only thing that beats the keyboard at formating is formating automatically from a database. The mouse and eye can't simply match the fastness, efficiency and accuracy of trained personnel's fingers on a keypad. :) Being a keyboard junkie myself (OK, context menu as well), it's hard for me to disagree :) The advantages of database formatting have been recently mentioned in the fruitful discussion on collaboration on the list. Moreover, the use of character styles/style sets would enhance the opportunities compared to the original suggestion. The basic point of this discussion is how to implement substyles. This is a question of implementation in the file format and the UI. Mapping the styles to shortcuts is secondary since it can be done by the user, provided the software allows for it. Just to bring us back on track :) |
|
|
If not duplicates, then this bug at least is tightly related to that one: http://bugs.scribus.net/view.php?id=5196 |
- Anonymous
