[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] Current/default font
- From: Martin Wuerthner <lists@xxxxxxxxxxxxxxx>
- Date: Thu, 27 Jul 2006 14:32:54 +0200
- Subject: 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.
Martin