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

Re: [XaraXtreme-dev] Current/default font

In message <44C8A7C6.2090700@xxxxxxxxxxx>
          Alex Bligh <alex@xxxxxxxxxxx> wrote:

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

Yes, precisely.

> 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 is what ArtWorks did (probably would not mean much to you, but to 
some others), but Camelot works differently. The default attributes 
are abstract and fixed.

> * 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
                          ^^^ Times New Roman

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

Fortunately, this is not a problem because there never can and never 
will be a system with a different default font attribute.