Re: [XaraXtreme-dev] Substituted fonts and Bug 1057

[Martin Wuerthner <lists@xxxxxxxxxxxxxxx>]

In message <E3A254B6215990935DE95BC7@[192.168.100.25]>
          Alex Bligh <alex@xxxxxxxxxxx> wrote:

> Bug 1057 appears in essence because the font dropdown code cannot display
> anything other than fonts that are enumerated. There is no way for it
> (currently) to get font names and types other than through the current font
> enumeration.

Not really true. The dropdown list is in no way tied to the font 
enumeration. For instance, it is pretty trivial to add further entries 
if we want, e.g., getting all substituted fonts from the kernel.

> Enumeration doesn't (currently) enumerate fonts that are
> substituted, hence the string appears blank.

I do not think the standard enumeration mechanism should ever list 
fonts that are substituted, but there is no reason why we could not 
have an additional service that lists both the installed and 
substituted fonts. It is pretty easy to get the substituted fonts 
directly from the kernel, so an additional service is probably not 
even necessary.

> Q1: Should it be possible to select a font which is not present
> on the machine (but is present in the document and has an appropriate
> substitution) using the drop down menu? I say yes. There are many reasons
> you might wish to do this (for instance you load a .xar on one machine
> without a particular font installed and want to add - say - a page number
> at the bottom of the page in the right font - you can do this ANYWAY by
> laboriously going to find a text story in that font, copying it, pasting it
> at the bottom of the page, and changing its text, size, fill colour etc. -
> so why not let them just pull it off the menu)? Obviously, the font should
> indicate it is missing (my proposal would be to put a '?' instead of the TT
> icon on the menu or similar).

The problem I see is that after loading a couple of documents with 
missing fonts you will end up having lots of "?" entries in the 
dropdown list. I think having these entries confuses users, even more 
so as many of these fonts will probably be substituted by the default 
font and hence look the same. It might be acceptable if the list only 
showed the substituted fonts in the current document, but currently, 
we do not have any data structures to get at them.

> This alone would fix bug 1057 (in that the
> field on load would then say "Arial" with a question mark, which would work
> 'out of the box' because Arial will now be on the font menu).

Unfortunately, that would not immediately fix it. I have tried it by 
changing the dropdown menu code to include substituted fonts (as I 
indicated above, this information is easy to get from the kernel). 
This still fails in the case when the text tool is the default tool at 
start-up because the text tool is initialised before the default 
document is loaded. The text tool builds the font list when it is 
selected (i.e., at start-up if it is the default tool), so the list at 
that time does not include the substituted font.

> The alternative view (this is Martin's view I think), is that the font
> menu should only display fonts that are installed on the machine (as
> opposed to fonts it is possible to put in your document). In this
> view, we shouldn't be offering the user the chance to put in
> substituted fonts (at least easily) presumably because it will only
> encourage them to think the fonts are present on the machine.

Yes.

> Q3: Should we recode the font drop-down to display the font name of
> a substituted font even when it isn't selectable through the drop-down
> menu? This is in essence what Martin proposes. It is clearly unnecessary
> if you do what I propose w.r.t. Q1 as the font will always be on the
> dropdown menu. It also would involve not only a rework of our own font
> combo, but it may not work using wxOwnerDrawnComboBox without some
> non-trivial modification to the wx class - read only combo boxes are
> assumed to have a selected value which is in the drop-down list - that's
> pretty much how they work. Of course it would not be impossible, but
> it is non-trivial

Would it not be possible to change the box to a read-write combo box, 
which would not suffer from that restriction? I have very often wished 
to be able to click in the field and type "Arial"+Return rather than 
having to scroll a huge list to find an entry I know is there.

Martin