|
2005-07-22 15:14
|
Foto1.png (11,993 bytes) |
|
2005-07-22 15:17
|
Foto2.png (12,915 bytes) |
|
|
Yep, that bit of the dialog needs a bunch of work. The innards of the dialog need a lot, too. Personally, I'd prefer to have a list of fonts with a three-way radio button for each - "embed", "subset", or "omit". |
|
|
>>>Personally, I'd prefer to have a list of fonts with a three-way radio button for each - "embed", "subset", or "omit". Excellent idea! But check boxes for "embed all", "subset all" and "convert all to outline" at the top of the dialog should remain. Another problem might occur once PDFs are no longer rasterised on import. Technical issues aside, how to deal best with embedded/subset fonts in those PDFs in the dialog? |
|
|
PDF/X-3 by the spec, must have all fonts embedded. Yes, there might be a widget issues for sure though. |
|
|
>> >>>Personally, I'd prefer to have a list of fonts with a three-way >> radio button for each - "embed", "subset", or "omit". >> >> Excellent idea! But check boxes for "embed all", "subset all" and >> "convert all to outline" at the top of the dialog should remain. The list is an excellent idea! But could a "embed all", "subset all" and "convert all to outline" not be done by buttons instead of check boxes? Stayes the problem to restrict the choise when PDF/X3 is produced. This could be done be disabling the corresponding column of radio buttons. |
|
|
>>>But could a "embed all", "subset all" and "convert all to outline" not be done by buttons instead of check boxes? Actually, I don't see a problem here. What would be the advantage of buttons over check boxes? Maybe I'm just missing something. I'm curious what you mean. >>>Stayes the problem to restrict the choise when PDF/X3 is produced. This could be done be disabling the corresponding column of radio buttons. Yes, that makes sense. If PDF X/3 is selected for output, "embed all" should be enabled by default. "Convert all to outline" would also be offered. The font list has to be greyed out in this case. |
|
|
>> >>>But could a "embed all", "subset all" and "convert all to outline" >> not be done by buttons instead of check boxes? >> >> Actually, I don't see a problem here. What would be the advantage of >> buttons over check boxes? Maybe I'm just missing something. I'm curious >> what you mean. I mean that: For example you choose the checkbox "Subset all". In that moment, all radio buttons are changed to "subset". Than, perhaps, you change one of the fonts to "embed". What happens now with the checkbox? In the aktual version 1.3.0, it stays checked, and this behavior is bad because one font is NOT subsetted. At least the checkbox shold become unchecked in this case. But I just imagine that most users expect, when they check a checkbox, that this choise is permanent and ui-elements who are opposite to this choise are disabled. (And this behavior also occurs often in Scribus.) |
|
|
>>>I mean that: For example you choose the checkbox "Subset all". In that moment, all radio buttons are changed to "subset". Than, perhaps, you change one of the fonts to "embed". What happens now with the checkbox? In the aktual version 1.3.0, it stays checked, and this behavior is bad because one font is NOT subsetted. At least the checkbox shold become unchecked in this case. >>>But I just imagine that most users expect, when they check a checkbox, that this choise is permanent and ui-elements who are opposite to this choise are disabled. (And this behavior also occurs often in Scribus.) OK, now I got it. How about that solution: Use check boxes. If you choose "subset all", the radio buttons are greyed out and all buttons set to "subset". If you now want to exclude one or more fonts, you have to "unlock" the font list by unchecking the box. Now you can deselect fonts (omit, embed all, convert to outline). |
|
|
That's a good idea! It keeps the interface clear und is easily to understand for the user. |
|
|
Just a thought. I think there is definitely a need to help users make their choice by providing info on just what each option is all about. For instance, while "Embed all fonts" might sound self-explanatory, I know many people who don't have a clue of what's going to happen to their document when they check that option. When it comes to "Subset font" it's even worse. As for "Convert all to outline", well... I think this one is clear but again, how can we be sure people fully understand what's the effect of this on their document? I have read many (many many!) posts on the list that lead me to think "font" features in PDFs taken as a whole are one of the most unclear feature (in DTP in general, not a Scribus exclusivity). Tooltips are great for this. |
|
|
Hi Louis, you are definitely right with your demand for good tooltips. They are quite good in scribus right now, but there is always room for improvement. OTOH, software like scribus or QXP is not made for Joe Average. DTP is -- by definition -- a complex issue, and I would expect from users to read the documentation or at least parts of it. One can't put the whole of the docs into the tooltips. But then I still know some QXP users, good designers BTW, who have no clue about font issues, because printers accepted *.qxd files anyway. And the former "golden rule" (always use type 1 fonts) seems to be enough for them. Maybe it would be useful to have a "hints" window turned on by default like many other FOSS apps do. "Please read the docs" should be hint number one ;) Speaking of Quark: QXP's PDF export options are actually *much* worse and less intuitive than scribus' -- unless you use Acrobat for PDF output. |
|
|
With such a lively discussion this issue isn't really "new" :-) BTW, for Scribus "subset font" is "convert to outline". That might change in the future, though. |
|
2006-05-07 17:58
|
screenshot2.png (36,366 bytes) |
|
|
In bug 0003701 an instresting discussion about the font embedding dialog has taken place. Also here, a lot of proposals where made. I try to make a new proposal for the UI considering these discussens: The approach should also take in mind that maybe one day, subset will not mean "convert to outline" (like it is actually for all font types: Type1, TrueType and OpenType, but real subsetting at least for some of these types (and for OpenType not or only up from PDF 1.6, like avox remembered). For this reason, "subset" should be renamed to "convert to outline" (and also saved to files in this way). This makes clearer what really happens, and support for real subsetting can be added later in an consistend way. The approach should be reliable enough to deal with all this combinations of "code for this not avaible" or "not avaible with this PDF version". Instead of the actually used 3 different list boxes, it is prefered to use one big list of all fonts. For each font, in this list can be choosen if he becomes embedded, subseted etc. First column contains the font name and an icon indicating the font type. This is usefull, because for some font types (like OpenType), not all options are avaible. (An alternative would be to have an extra column with the font type symbol and the font name. This needs more place, put would be clearer.) The proposel discussed here was to realize the choise with a 3 way radio button. But this becomes easily unhandy (like it is actually the case with the dialog in File->Preferences->Fonts: the width is very big). I would prefer instead a combo box providing the avaible choises. This is much more comfortable to use. Options who aren't avaible for this font won't show up in the list. There is a need of fast chooses like "Embed all fonts completly" or "Convert all fonts to outline". Using checkboxes is confusing. Using buttons (as I proposed here) has also disadvantages. IMHO it would be the best choise to use radio buttons specifiing "Embed all fonts completly", "Subset all fonts", "Convert all fonts to outline", "Don't embed fonts" and "Determinate individually". The first three options whould gray out the font list. Only with "Determinate individually", changes in the font list would be possible. This approach is clear and easy to understand. Furthermore, when new fonts are added to the list, and one of the first 3 options is choosen, this option is also applied to the new font - actually you don't always get what you expect. But there stay 2 problems: 1. What happens, when you choose a radio button (for example "Embed all fonts as subset"), but this option isn't avaible for a font in the list (remember: OpenType fonts are converted to outline.)? In this case, the list should follow this police: first try if the next better option (here: "Embed completly") is avaible. If yes, choose this. Else next better option etc. If none of the "better" options is avaible, the next worser option (here: "Convert to outline") should be choosed. 2. What happens when the options avaible by the pdf export code have to be restricted (exporting PDF/X-3: "don't embed" can't be choosed here.)? a.) The radiobutton "Don't embed" becomes grayed out. If it was choose formerly, choise is changed to the next better: "Convert all fonts to outline". b.) If "Determinate individually" was choosen, this choise stays like it is. In all comboboxes, the entry "Don't embed" becomes grayed out. If he was choosed formerly, choise is changed to the next better: "convert to outline". (As a side effect: There are 2 possiblities why an option isn't avaible for a font: because the pdf export code generally doesn't support this option, or because this option isn't avaible with the actual settings like PDF/X3. This 2 different reasons can be reflected differently in the UI: If the option is generally not avaible, it doesn't even becomes displayed in the combobox. If it isn't avaible only with actual settings, the option stays in the combobox, but grayed out.) So, restrictions to the avaible options due to a change of the PDF version are handled following always the same police (concerning the general radio buttons and concerning the individual font comboboxes): first try better choises, than worser ones. So, the user can be shure that he gets what he expects. A "screenshot2.png" is attached. What do you think about? |
|
|
timi, that would be great. Will this problem be solved in 1.3.3.x version of Scribus? It's rather important for me because I can't embed some fonts (only convert to outline works, if I try to move them to the embedded list, they go back to the left list and aren't embedded - fe. Georgia font). (Sry for my English) |
|
|
1.3.3.x will not be changed from what it is doing now. 1.3.4 does. |
|
|
As far as I am concerned, I think the image Foto1.png by far gives the best solution. That way I may--with just one glance--understand how many fonts ar embedded, outlined/subset or not embedded at all. If I have to look at each and every font and se what is written behind it like this: embed dont't subset subset embed it is far more complicated to spot that 2 fonts are embedded, 2 subset and one not embedded. That means: The option of one big list (screenshot2) is not good at all, in fact it becomes *very confusing* and *looks untidy* -- everything just thrown in the same bowl instead of nicely separated and easily understood. The three boxes with the arrows are *neat, easy to grasp and visually nice to the eye* (should not that be important for a DTP application? :-P) I vote strongly for Foto1 of the above solutions |
|
|
Well, I'm not a developer and so I won't decide how the things will go, but just some thoughts: >> That way I may--with just one glance--understand how many fonts >> ar embedded, outlined/subset or not embedded at all. I don't see the benefit here. >> in fact it becomes *very confusing* and *looks untidy* In fact it is much more confusing using my first proposal from Foto1.png. As discussed above, it will be nessecary to deal not only with 3 ways of embedding, but additionally with "convert to outline". So you need yet 4 fields and you will have problems to move fonts from the 2. to the 4. field. Furthermore you have to deal with different PDF versions: some PDF versions support OpenType, others not. You have to deal with different font types: OpenType for example can never be embedded. And you have to make all these things transparent for the user. See comment 0011063. |
|
|
Avox has changed this menu recently and I think the changes have rendered some of this issue obsolete. |
|
|
I would consider this as solved in 1.5.1svn. So I propose to close this issue (resolution=fixed). |
|
|
Thanks timi, there are still some interesting aspects to this report that need a more in depth analysis for example the screenshot2 mockup. I'm resolving for now to differentiate this ticket. But won't close yet unless a dev specifically asks. |
|
|
adding screenshot2 to 0003701 and closing this ticket |
|
|
removed 1.6 Target and closing |
- Anonymous
