View Issue Details

IDProjectCategoryView StatusLast Update
0002276ScribusUsabilitypublic2015-12-02 12:56
Reportertimi Assigned Tojghali  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version1.3.0 
Fixed in Version1.5.1svn 
Summary0002276: The register "Fonts" in the dialog "Save as PDF" is quite confusing (and has a bug).
DescriptionThe register "Fonts" in the dialog "Save as PDF" is quite confusing (and has a bug).

- When you choose PDF/X3, it's impossible to move the fonts from "Fonts to embed" to "Fonts to subset". This is only possible after choosing "Subset all fonts". When doing this, "Embed all fonts" in unchecked. But when you move the fonts by hand from "Fonts to subset" to "Fonts to embed", "Subset all fonts" stays checked. This behavior is confusing.

- The sense of the two checkboxes stays unclear for a beginner. Do they mean that a certan options are hold by disabling some widgets? Or do they mean that a certan options are set but not hold (this would be the functionality normaly provided by a button)?

- When selecting a font from "Fonts to subset" and pushing the button with the "up"-flash, the font is moved from bottom to top. When selecting. When selecting a font from "Avaible Fonts" who is yet also in "Fonts to subset", the font is COPYED to "Fonts to embed" and now presend in all the 3 lists!!! When selecting a font from "Avaible Fonts" who is yet also in "Fonts to embed", nothing happens. --- All this is quite confusing.

So I propose to change the design of the dialog a little bit. The list "Avaible fonts" could be replaced with a list "Don't embed". So, EVERY font present in EXACTLY ONE list - that's more intuitiv and clear. There exist buttons for all possible move directions - they are enabled or disabled depending of the actual situation (Foto1.png).
When "Embed all fonts" is selected, the "Don't embed"-label and the corresponding list are disabled. All fonts from "Don't embed" are moved to "Embed completly".
When the PDF-version is PDF/X3, "Embed all fonts" becomes checked and disabled. When then another PDF-version is selected, "Embed all fonts" becomes enabled and stayes checked. This behavior is transparent for the user.
The checkbox "Subset all fonts" is no longer present. IMHO this is no so important and confuses more than it helps. But when the functionality is absolutly needed, there could be 4 instead of 2 buttons to the fonts from one list to the other - in the center the normal buttons moving 1 font, and at the left and at the right (or on top/on button) buttons with big flashes moving ALL fonts.
TagsNo tags attached.
PatchNo

Relationships

duplicate of 0003246 closed confusing UI with embed/subset fonts 
related to 0004546 closedfschmid PDF Export: Despite "Do not embed fonts, do not subset" settings, Scribus converts fonts to outlines 
related to 0003701 assignedavox PDF export: better UI for Font Embedding 

Activities

2005-07-22 15:14

 

Foto1.png (11,993 bytes)   
Foto1.png (11,993 bytes)   

2005-07-22 15:17

 

Foto2.png (12,915 bytes)   
Foto2.png (12,915 bytes)   

ringerc

2005-07-22 16:10

reporter   ~0005659

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".

christoph_s

2005-07-22 18:59

administrator   ~0005660

>>>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?

plinnell

2005-07-23 08:38

viewer   ~0005669

PDF/X-3 by the spec, must have all fonts embedded.

Yes, there might be a widget issues for sure though.

timi

2005-07-23 08:55

reporter   ~0005670

>> >>>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.

christoph_s

2005-07-23 18:37

administrator   ~0005675

>>>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.

timi

2005-07-23 20:11

reporter   ~0005676

>> >>>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.)

christoph_s

2005-07-23 20:51

administrator   ~0005677

>>>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).

timi

2005-07-24 10:23

reporter   ~0005689

That's a good idea! It keeps the interface clear und is easily to understand for the user.

louisdesjardins

2005-07-24 11:52

developer   ~0005691

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.

christoph_s

2005-07-24 23:44

administrator   ~0005702

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.

avox

2005-07-25 13:25

administrator   ~0005714

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)   
screenshot2.png (36,366 bytes)   

timi

2006-05-07 17:59

reporter   ~0011063

Last edited: 2015-12-02 12:50

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?

Magnes

2007-02-06 07:43

reporter   ~0015113

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)

cbradney

2007-02-06 09:46

administrator   ~0015116

1.3.3.x will not be changed from what it is doing now. 1.3.4 does.

axelb

2007-02-07 23:42

reporter   ~0015132

Last edited: 2007-02-07 23:49

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

timi

2007-02-08 10:06

reporter   ~0015145

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.

Kunda

2015-06-25 23:25

updater   ~0035513

Avox has changed this menu recently and I think the changes have rendered some of this issue obsolete.

timi

2015-11-08 11:26

reporter   ~0037318

I would consider this as solved in 1.5.1svn.

So I propose to close this issue (resolution=fixed).

Kunda

2015-11-09 09:38

updater   ~0037333

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.

Kunda

2015-12-02 12:54

updater   ~0037789

adding screenshot2 to 0003701 and closing this ticket

Kunda

2015-12-02 12:56

updater   ~0037791

removed 1.6 Target and closing

Issue History

Date Modified Username Field Change
2005-07-22 15:14 timi New Issue
2005-07-22 15:14 timi File Added: Foto1.png
2005-07-22 15:17 timi File Added: Foto2.png
2005-07-22 16:10 ringerc Note Added: 0005659
2005-07-22 18:59 christoph_s Note Added: 0005660
2005-07-23 08:38 plinnell Note Added: 0005669
2005-07-23 08:55 timi Note Added: 0005670
2005-07-23 18:37 christoph_s Note Added: 0005675
2005-07-23 20:11 timi Note Added: 0005676
2005-07-23 20:51 christoph_s Note Added: 0005677
2005-07-24 10:23 timi Note Added: 0005689
2005-07-24 11:52 louisdesjardins Note Added: 0005691
2005-07-24 23:44 christoph_s Note Added: 0005702
2005-07-25 13:25 avox Note Added: 0005714
2005-07-25 13:25 avox Status new => acknowledged
2006-02-16 08:28 jo-hannes Relationship added duplicate of 0003246
2006-04-27 22:07 mhanski Relationship added related to 0002057
2006-04-27 22:08 mhanski Relationship deleted related to 0002057
2006-05-03 12:42 mhanski Relationship added related to 0003701
2006-05-07 17:58 timi File Added: screenshot2.png
2006-05-07 17:59 timi Note Added: 0011063
2006-11-17 02:08 mhanski Relationship added related to 0004546
2007-02-06 07:43 Magnes Note Added: 0015113
2007-02-06 09:46 cbradney Note Added: 0015116
2007-02-07 23:42 axelb Note Added: 0015132
2007-02-07 23:48 axelb Note Edited: 0015132
2007-02-07 23:49 axelb Note Edited: 0015132
2007-02-08 10:06 timi Note Added: 0015145
2015-02-19 06:43 cbradney Status acknowledged => assigned
2015-02-19 06:43 cbradney Assigned To => jghali
2015-06-25 23:25 Kunda Note Added: 0035513
2015-06-25 23:26 Kunda Patch => No
2015-06-25 23:26 Kunda Target Version => 1.6 milestone
2015-06-25 23:26 Kunda Description Updated
2015-11-08 11:26 timi Note Added: 0037318
2015-11-09 09:38 Kunda Note Added: 0037333
2015-11-09 09:38 Kunda Status assigned => resolved
2015-11-09 09:38 Kunda Fixed in Version => 1.5.1
2015-11-09 09:38 Kunda Resolution open => fixed
2015-11-09 10:00 jghali Fixed in Version 1.5.1 => 1.5.1svn
2015-12-02 12:50 Kunda Note Edited: 0011063
2015-12-02 12:54 Kunda Note Added: 0037789
2015-12-02 12:56 Kunda Note Added: 0037791
2015-12-02 12:56 Kunda Status resolved => closed
2015-12-02 12:56 Kunda Target Version 1.6 milestone =>