Re: [XaraXtreme-dev] Current/default font

[Alex Bligh <alex@xxxxxxxxxxx>]

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.

Sound OK?

Alex