[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] Current/default font
- From: Alex Bligh <alex@xxxxxxxxxxx>
- Date: Thu, 27 Jul 2006 12:47:18 +0100
- Subject: Re: [XaraXtreme-dev] Current/default font
Charles Moir wrote:
Ha - we're all in the same boat. We all knew we debated it for some time
(it's pretty complicated to grasp all the pros and cons), came to a
conclusion we were all happy with, and now can't remember why!
And yes I'm thinking the same - without spending an hour or so thinking
it all through again I was just sure the original conclusion we came to
was the correct one, and would be reluctant to deviate from that (given
how long we debated it).
OK. So let's just set out simple questions at a technical level Phil
can answer which will satisfy us all:
Martin's assertion in Bug 1111, is that if we examine both the
default and the current font attributes to see whether the
font that is encoded there-in is absent, we will end up with
the situation where we change BOTH the current and the default
attributes (e.g. from "Arial" to "Vera"). He then says, that
if any text is typed, though it will come it Vera, it won't
need any attributes within the tree as it will simply rely
on the default attributes by attribute optimization. The
problem with this (per Martin), is that when the document
is saved, it won't have any attributes in at all (as
default attributes are not saved). This will lead to the
situation where if reloaded on a system where both
Arial and Vera are present (and thus Arial remains the
default attribute), it will be rendered in Arial without
warning the user of any substitution.
My response to that is two fold:
* I thought we /always/ saved (in the file format) a set
of attributes at the top of the tree, so the problem
would not occur. This was based on my understanding
of what Phil said (I may have misunderstood).
* If Martin is correct, then we have a different additional
problem: That is that his argument also applies to existing
Xtreme installations. If it really is the case that
when the default attribute is used, no font attribute
at all is saved in the document, then any document out
there right now with Arial (only) in, has no font attribute
encoded in the document at all. This would mean that if
you load such a document on a system with a different
default font attribute, it won't render as Arial or
ask for font substitution. So the proposed solution (and
possibly Martin's variant) are broken for the case of
loading an existing document in.
So the question for Phil is quite simply:
Q: Assume that the current attribute and default attribute
specify the same font, and text is created using that font.
When the document is saved, is the font in an attribute
in the saved document? And if so, will that document
then load in the correct font, even if the
default attributes of the system loading the document
have a different font in to the saving system.
If the answer to the question is "Yes", Martin's problem
is based on an incorrect premise, and we should go with
the current system. If the answer is "No", the bugfix
has a flaw in. We then need to investigate whether Martin's
mod will fix not only the flaw he identified, but the
corollary of that flaw identified above.