[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] Substituted fonts and Bug 1057
- From: Phil Martin <phil@xxxxxxxx>
- Date: Mon, 22 May 2006 11:21:46 +0100
- Subject: Re: [XaraXtreme-dev] Substituted fonts and Bug 1057
Alex Bligh wrote:
[ I think this is probably easier to discuss on list rather than on
as there are at least three possible solutions, and two interrelated
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
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
(as opposed to default attributes), they are (or should be)
render time (as opposed to in the document) so if a small change is
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
the name of the font /before/ substitution, preferably with some
to show it isn't actually present. I think Martin and I agree on that
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,
at the bottom of the page, and changing its text, size, fill colour
so why not let them just pull it off the menu)? Obviously, the font
indicate it is missing (my proposal would be to put a '?' instead of
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
'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
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.