[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

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

Alex Bligh wrote:
[ I think this is probably easier to discuss on list rather than on Bugzilla 
 as there are at least three possible solutions, and two interrelated
 problems ]

PLEASE read and give opinions:

Bug 1057 is essentially a report that when the default document is loaded
on LX, the text tool combo field is blank (no font displayed). This
relatively simple bug is actually quite complex. It seems to me there
are several distinct problems. They include:

1. The default document ships with a default font attribute specifying
  a font that is not installed on any Linux machines by default (Arial).

2. There is a difference of opinion about how to handle fonts that
  are substituted. The difference of opinion is not a recent one (i.e.
  it predates LX) and is reflected in the different way different
  subsystems work and have always worked. So there is a question
  as to which one to fix. I guess this didn't appear as a problem because
  people don't normally work on docs with substituted fonts, let alone
  ones where the default attribute is a substituted font - see (1).

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. Enumeration doesn't (currently) enumerate fonts that are
substituted, hence the string appears blank. Whilst clearly this isn't
good, there are (at least) three ways to fix the bug. These depend on
how we want to deal with fonts that are substituted. See below.

When documents are loaded which contain fonts that are not present, they
are substituted. At least in the case of font attributes applied to objects (as opposed to default attributes), they are (or should be) substituted at render time (as opposed to in the document) so if a small change is made to 
the document, that change can be reflected in the document when saved
without also having the substituted font replaced with its substitution.
I think Martin & I are at one on that one.


Yes. This is an important feature.
When working with substituted fonts, the field in text tool should indicate the name of the font /before/ substitution, preferably with some indicator to show it isn't actually present. I think Martin and I agree on that much 
too.

So to the questions:

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

Q2: When a /default/ (or for that matter perhaps 'current') attribute is
to be set to a substituted font (or perhaps when a template is loaded),
should the substitution be permanent? EG if there is a template that
says "Arial" in it as a substituted font, which is only ever used as
a default attribute, there is nothing particularly useful in preserving
Arial across a font substitution. Every time a saved-out document is
reloaded, it will warn about the missing font. Is this actually useful
behaviour, or should the font be /permanently/ substituted (e.g.
in the attribute itself). This, it seems to me, is a bug irrespective
of whether people can apply substituted fonts to objects in the program.
Even if you disagree with my view on Q1, it seems to me daft to use
templates which produce documents which always warn on loading (or
rather would warn, if the warning message was there). Fixing this
(so that when loading a document the default font attribute is not
a missing font) would also fix Bug 1057 without any further recoding,
(irrespective of the answer to Q1) - it (alone) would not be enough
to make the font combo field always say something for instance when
an object with a substituted font is selected - we'd either need to
do what I propose in Q1, or do what Martin proposes (Q3). But this
would be enough at least to demote 1057 to non-P1. I'm not sure what
Martin's view on this one is. Martin?
The default attributes are not saved with the document. They are added to the doc programmatically when it is loaded. (This was done to reduce XAR file size many years ago...) It may be possible to leverage this feature to ensure that the default font face attribute always refers to an Arial equivalent on the native machine???
Current attributes are (optionally) saved with the document. I think a permanent substitution of the current font face attribute wouldn't be nice because it's a hidden change meaning that a document could be subtly changed simply by loading and saving it but since it's not changing any rendered part of the document it might be acceptable. 



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, so we should decide what we are doing about Q1 (and
possibly Q2) first. Martin's view is that I should fix this :-) I want
to avoid it if I can because it's pretty intrusive.

Alex