[Libreoffice-bugs] [Bug 136434] FORMATTING: redundancy in content.xml
bugzilla-daemon at bugs.documentfoundation.org
bugzilla-daemon at bugs.documentfoundation.org
Tue Oct 13 20:02:07 UTC 2020
https://bugs.documentfoundation.org/show_bug.cgi?id=136434
--- Comment #13 from Christian Lehmann <christianw_lehmann at arcor.de> ---
(In reply to Mike Kaganski from comment #11)
> > It appears we are talking past each other. What matters to the user is what
> > he can see in the editing window. The nine font declarations mention fonts
> > like 'Lohit Devanagari', 'Noto Sans CJK' and the like, none of which are
> > visible to the user in this particular document, be it in direct formats, be
> > it in the styles applied. I conclude that this information (whatever its
> > origin) does not need to be stored in the file.
>
> It only is "not visible" to you because you chose not to see it: namely, you
> likely don't have Asian and CTL support enabled in Options->Language
> Settings->Languages. It is *hidden* from people that don't choose to see it,
> but it doesn't mean it's inaccessible, or that it should be dropped. The
> styles (and direct formatting) has the full set of settings that describes
> its appearance, which includes possibility that someone later types a
> Chinese or Arabic characters there in that paragraph.
Indeed, I had not. Even if I activate those languages, the 'Asian Text Font'
and the 'CTL Font' offered for use are different. And the two fonts I mentioned
are not even offered in the dropdown list.
Moreover, activating this option would introduce the possibility of using two
additional fonts. Why should there be nine of them?
> > > See comment 3.
> > That is certainly a helpful hint. However, again, why would you want to
> > store this information with the file, if it is inaccessible the user?
>
> It is available - when user uses Edit->Track Changes->Compare Document.
>
The point was not whether this can be made visible to the user (I have not
succeeded using this method), but whether this information is of any use to
him.
> >
> > >
> > > > Styles T4 – T6 contain specifications of fonts which are never used.
> > >
> > > This doesn't make sense. The fonts are "used" as soon as the style is used.
> > > If characters present in a text run that uses the style (DF actually) don't
> > > need some script, that doesn't mean "the style should be cleaned up, such as
> > > when user finally decides to write some Arabic or Chinese characters, they
> > > would appear in something else compared to what had been defined originally".
> >
> > Again, this answer doesn't make sense to me. Let's consider an example: The
> > XML alleges that a style named 'T4' is applied to the word 'block' in the
> > file. This fact, however, is not visible to the user. In his perspective,
> > the entire paragraph is formatted with the Default Character Style. "T4" is
> > in no way accessible to him.
>
> The automatic styles is the LibreOffice way to express direct formatting. So
> T4 *is* available to user, through properties of the text that has this
> automatic style applied.
>
We are talking about parsimony. Why do we need T1 - T14, each with its own
definition, if most of them appear as the same to the user?
> >
> > This is true. Since it is not an LO Writer Style, it probably stems from an
> > earlier MS Word version of the document. Again, the question is why a style
> > that was specified at the level of a block - in this case, a comment - is
> > assigned to single elements contained in the block.
>
> This is not related to this issue, and is something to ask the author.
No, it is an issue of how LO Writer stores a character style that the user
specified for an entire paragraph. I had asked this in a different bug report
and will take it up there.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20201013/6f4b6665/attachment-0001.htm>
More information about the Libreoffice-bugs
mailing list