Consider attachment 83968 [details]
In the first three rows, the body is always displayed (in these cases,
the office:value attributes properly overrides the child text:p),
but it is always *treated* in some way. In particular, <text:variable-set>
tags are treated. See that variables (foo|bar)Apr(Pri|Sec) as well as
(foo|bar)AugPri are set, and displayed in the page footer:
On the other hand, for cells with office:value-type="string"
(rows August Secundo and August Tertio), as soon as there is
an office:string-value (that is, the second column), the
<text:variable-set> in the body are not evaluated; the variables
fooAug(Sec|Ter) stay at "0". This is what causes bug 67930. In the
absence of an office:string-value, however, the body is displayed
and executed, and the barAug(Sec|Ter) variables do get set.
It should be coherent, and *always* evaluate <text:p> within
Actually, even <text:variable-set> in a cell of type void is evaluated.
This is a regression compared to 18.104.22.168; most probably introduced by the fix to bug 60842:
fdo#60842: sw ODF import: support value-type="string" on cells
Lionel - Who should address this bug?
(In reply to comment #3)
> Lionel - Who should address this bug?
I hoped that Michael Stahl would address it, since he addresses similar / related bugs. Failing that, some other Writer hacker / expert / ...?
(In reply to comment #4)
> (In reply to comment #3)
> > Lionel - Who should address this bug?
> I hoped that Michael Stahl would address it, since he addresses similar /
> related bugs. Failing that, some other Writer hacker / expert / ...?
In general, QA has been using the 'NeedAdvice' tag to mark bugs that need to be escalated up for a dev to evaluate. I'd like to see bugs be addressed by a dev within perhaps a month of being tagged -- having bugs sit in this state for months at a time makes it harder for us to filter on this tag and get a list of actionable bugs.
I'd appreciate it if anyone who tags a bug as NeedAdvice makes sure to follow-up on the bug at least once a month and see what they can do to spur our existing devs to comment on the results. If a bug really isn't actionable for a while, I'd be open to introducing a new tag 'NeedAdviceInTheFuture' to separate-out these particular outliers.
(Removing NeedAdvice tag)
Lionel - Please feel free to set the status of these regressions directly to NEW.
(This is an automated message.)
It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.)
Thus setting keyword "bisected".
sigh... retyping comment since bugzilla ate it...
that we import the field for value-type="float" or value-type="void"
sounds like a bug to me.
ODF 1.2 19.385 office:value-type is quite clear that the value
from office:string-value takes precedence over the element content.
the value of the table cell would include any fields or other
formatting in the element text, which obviously can't be
encoded in an XML attribute.
so from that it doesn't make sense to add an office:value-type
attribute on a cell that has content that isn't just plain text.
another point of view would be that the ODF spec has a bug here
and that office:string-value should not take precedence over the
office:value-type="string" already differs from the other types
in that for the other types the *-value attribute is mandatory and
the element content is merely a "preview" text rendering for "dumb"
consumers with some particular # of digits etc.,
which is not a concern if the type is string.
was wondering why the office:string-value exists at all;
Eike said that you can create a number format like this:
and it will append "foo" to the text in the cell.
Calc implements this well, in Writer you can do this
in the UI but if you look at the exported ODF file it's
quite some nonsense :(
(In reply to Michael Stahl from comment #8)
> so from that it doesn't make sense to add an office:value-type
> attribute on a cell that has content that isn't just plain text.
of course i meant "office:string-value" here.
(In reply to Michael Stahl from comment #9)
> was wondering why the office:string-value exists at all;
> Eike said that you can create a number format like this:
> @ "foo"
> and it will append "foo" to the text in the cell.
And then, if there were no office:string-value, the original value (pre-formatting) would be "lost" (or, let's say, unduly hard to retrieve), since only the post-formatting result would be stored in the file.
This works only for non-formatted strings; this is obvious from the POV of the file format, but IMHO quite surprising for the "naive" user. <shrug>
(In reply to Michael Stahl from comment #8)
> that we import the field for value-type="float" or value-type="void"
> sounds like a bug to me.
<big sigh> Report Builder relies on it :-|
Adding bibisected to whiteboard as bisected keyword is a subset of bibisected whiteboard.
about the handling of "float" fields, see my comment on bug 68022
Migrating Whiteboard tags to Keywords: (bibisected)
Adding Cc: to Michael Stahl
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!