Re: [XaraXtreme-dev] Current/default font

[Martin Wuerthner <lists@xxxxxxxxxxxxxxx>]

In message <44C8CA9E.3040500@xxxxxxxxxxx>
          Alex Bligh <alex@xxxxxxxxxxx> wrote:

> Martin Wuerthner wrote:
>> The question really is whether or not we want these typeface
>> attributes for text in the default font. This behaviour is different
>> from all other attribute types and it makes the default attribute
>> system pretty pointless for font attributes.
> 
> If we are sure the Default font attribute is never used (because
> there is always one below it in the tree), I'd be quite happy
> documenting this, change it not say "Times New Roman" but some
> default value (like an empty string) and ENSURE if we ever
> try rendering it.

I do not think this is a good idea. We really should not have special 
behaviour just for one attribute type. All the other default 
attributes are really used and if an object has the default value it 
does not have its own copy of the attribute.

Fortunately, having the extra font attributes in the tree does not do 
any harm, it just means we are missing a slight space optimisation, 
which we do for all other attribute types. So, one of the two main 
purposes of the default attribute system (saving space) is effectively 
disabled for text font attributes (the other one being ensuring that 
each object always has its required attributes applied even in case 
some object handler incorrectly forgets to apply the current 
attributes when the object is created - which should never happen, of 
course, but does happen in same special cases in ArtWorks, in which 
case there is still the problem that the properties of the object 
change spontaneously from what they were to the default attribute 
value).

The optimisation gain would not be terrifict though. Basically, as 
soon as you change the initial current attribute to be different from 
the default attribute (as it happens with text font and font size) 
then you lose most of it because if the user does not care about the 
property and just creates an object, it will not have the default 
attribute and thus have its own attribute node.

> This would obviate the need to do the substitution.
> In effect I think you are saying it actually works like this already
> in the document (as well as in the file on disk) which I didn't
> know. It's having an attribute hanging around that looks like
> it's in an uninstalled font which is the bad thing as far as I'm
> concerned.

I do not think this does any harm as is. In my opinion, it would do 
harm to change it, though not as much as I originally claimed. 
However, it would still do harm because if we ever release a version 
of Camelot that *does* change the default font attribute of a 
document, then, from that moment on, we will not be able to fix the 
idiosyncratic behaviour of font attributes in some future version 
because such a future version will then save documents with text in 
Times New Roman that does not have a font attribute.

Martin