Is this a misunderstanding from my side?  If I open the attached odt file then it has already four pages and the title is going over two lines.

Probably because you do not have the Helvetica Neue fonts on your system, and they get replaced by something else.

It will be hard to reproduce anything using font adornments if you don't have the same fonts used from the example.

(In reply to Dag Wieers from comment #2)
> Probably because you do not have the Helvetica Neue fonts on your system,
> and they get replaced by something else.

Hi Dag,
Some quick searching dug up this page:
http://www.linotype.com/1266/neuehelvetica-family.html

Is there a way for us to test against the Helvetica Neue fonts for free?

> It will be hard to reproduce anything using font adornments if you don't
> have the same fonts used from the example.

Fair enough. Could you please attach screenshots for how the document appears as ODT, DOC, and DOCX?  (Even if we don't have the fonts, I'm interested in seeing how bad the output becomes)

Right, I didn't think of that. Sorry.

You can see the results online at:

    http://dag.wiee.rs/cv/curriculum-vitae-dag-wieers.pdf
    http://dag.wiee.rs/cv/curriculum-vitae-dag-wieers.odt
    http://dag.wiee.rs/cv/curriculum-vitae-dag-wieers.doc

The PDF shows what it should really look like. But since an incorrect "subfont" (adornment/style) is being used when exported to DOC the dimensions of the font break the title line in two and pushes everything of the first page. (Basically the same thing you see when you don't have that same font)

BTW I do not offer DOCX because it has many other issues that make it worse. DOC is pretty close to the PDF except the title font (because of the adornments issue).

If you like I can make another PDF of the DOC output, but I think you understand the problem now, it is pretty much like it is using the wrong font (even though the correct font is being displayed, but the adornment is incorrect).

PS If you're interested, I generate the FODT (and ODT) file directly from AsciiDoc and use LibreOffice to convert these files to DOC, RTF and PDF.

    http://dag.wiee.rs/cv/curriculum-vitae-dag-wieers.asciidoc

(In reply to Dag Wieers from comment #4)
> The PDF shows what it should really look like. But since an incorrect
> "subfont" (adornment/style) is being used when exported to DOC the
> dimensions of the font break the title line in two

Hmmm hmmm. Do you think other fonts might show the same behavior?  (I'm not sure about the best way to track down other fonts that have 'subfont' adornments in this fashion...)

I couldn't find any in my extensive font-list. And at some point in the past the Helvetica Neue fonts were not listed together, but much like other fonts were considered different fonts and had separate entries inside LibreOffice.

I am not sure when that changed, and even whether it was a change to LibreOffice that caused this behavior. I have all LibreOffice versions from 3.5 to 4.4 on my system and only noticed it during the 4.4 development phase. But when I went back and tried it on older LibreOffice versions, I noticed what used to work isn't working anymore.

Maybe a RHEL6 update to a font-library changed the behavior subtly, I really don't know. But as part of this change of behavior the ODF output became different. The font name is no longer different between Helvetica Neue UltraLight and Helvetica Neue Light, but the adornment change from Regular to UltraLight.

I know this explanation sounds strange, but I can prove the fact that the ODF output changed at some point in time because I have older generated ODT files and I had to change the generated FODT to accomodate this change in behavior.

So I just looked at older FODT files, and this used to work fine:

 <style:font-face style:name="sect0-font" svg:font-family="Helvetica Neue Ultra Light" style:font-family-generic="swiss" style:font-pitch="variable"/>
 <style:font-face style:name="sect1-font" svg:font-family="Helvetica Neue Light" style:font-family-generic="swiss" style:font-pitch="variable"/>
 <style:font-face style:name="sect2-font" svg:font-family="Helvetica Neue" style:font-family-generic="swiss" style:font-pitch="variable"/>

Since some time during 4.4 development (but also with older releases now) I have to generate this:

  <style:font-face style:name="sect0-font" svg:font-family="Helvetica Neue" style:font-adornments="UltraLight" style:font-family-generic="swiss" style:font-p itch="variable" fo:font-weight="100"/>
  <style:font-face style:name="sect1-font" svg:font-family="Helvetica Neue" style:font-adornments="Light" style:font-family-generic="swiss" style:font-pitch= "variable" fo:font-weight="100"/>
  <style:font-face style:name="sect2-font" svg:font-family="Helvetica Neue" style:font-adornments="Regular" style:font-family-generic="swiss" style:font-pitc h="variable"/>

In order to have the old behavior. But converting to DOC now fails to store these adornments (where in the past this was not necessary, because the fontname was sufficient).

Does this make any sense ? :-)

(In reply to Dag Wieers from comment #6)
> I couldn't find any in my extensive font-list. And at some point in the past
> the Helvetica Neue fonts were not listed together, but much like other fonts
> were considered different fonts and had separate entries inside LibreOffice.

Aha! The plot thickens..

> I am not sure when that changed, and even whether it was a change to
> LibreOffice that caused this behavior. I have all LibreOffice versions from
> 3.5 to 4.4 on my system and only noticed it during the 4.4 development
> phase. But when I went back and tried it on older LibreOffice versions, I
> noticed what used to work isn't working anymore.

Trying to figure out what changed on the system (as it sounds like it's more of a system issue?) sounds like the key here.

(In reply to Dag Wieers from comment #7)
> So I just looked at older FODT files, and this used to work fine:
> 
>  <style:font-face style:name="sect0-font" svg:font-family="Helvetica Neue
> Ultra Light" style:font-family-generic="swiss" style:font-pitch="variable"/>
> ...
> ...But converting to DOC now fails to store
> these adornments (where in the past this was not necessary, because the
> fontname was sufficient).
> 
> Does this make any sense ? :-)

It's at least a place for us to start. Let me see what one of the devs thinks about the change in font behavior.

Well, the problem is that not that much changes on RHEL6. So if I look at the last font-related changes:

 libobasis4.4-ooofonts-4.4.1.2-2.x86_64        Wed 25 Feb 2015 08:52:32 PM CET
 libobasis4.3-ooofonts-4.3.6.2-2.x86_64        Tue 03 Feb 2015 05:45:32 PM CET
 libobasis4.2-ooofonts-4.2.8.2-2.x86_64        Mon 08 Dec 2014 11:16:00 PM CET
 libXfont-1.4.5-4.el6_6.x86_64                 Tue 18 Nov 2014 08:57:50 PM CET
 fontconfig-2.8.0-5.el6.i686                   Tue 12 Aug 2014 10:25:13 PM CEST
 fontconfig-devel-2.8.0-5.el6.x86_64           Tue 12 Aug 2014 10:18:23 PM CEST
 fontconfig-2.8.0-5.el6.x86_64                 Tue 12 Aug 2014 10:17:10 PM CEST
 libobasis4.1-ooofonts-4.1.6.2-2.x86_64        Tue 29 Apr 2014 10:15:25 PM CEST
 libobasis4.0-ooofonts-4.0.6.2-2.x86_64        Sat 19 Oct 2013 11:22:02 PM CEST
 libobasis3.6-ooofonts-3.6.7.2-2.x86_64        Thu 25 Jul 2013 03:16:24 PM CEST
 libobasis3.5-ooofonts-3.5.7-2.x86_64          Thu 18 Oct 2012 09:56:27 PM CEST
 libobasis3.4-ooofonts-3.4.6-602.x86_64        Wed 14 Mar 2012 09:36:42 PM CET
 libobasis3.3-ooofonts-3.3.4-401.x86_64        Mon 17 Oct 2011 09:17:58 PM CEST
 xorg-x11-font-utils-7.2-11.el6.x86_64         Thu 06 Oct 2011 02:47:25 PM CEST

And I assume that fontconfig is the only one that could make a difference ? But the changelog doesn't really hint at anything:

 * Wed May 21 2014 Akira TAGOH <tagoh@redhat.com> - 2.8.0-5
 - Rename 25-no-bitmap-fedora.conf to 25-no-bitmap-dist.conf. (#1099546)
 
 * Fri Apr 25 2014 Akira TAGOH <tagoh@redhat.com> - 2.8.0-4
 - Fix SIGBUS when the cache directory is on NFS. (#1035416)
 
 * Tue Jun 29 2010 Marek Kasik <mkasik@redhat.com> - 2.8.0-3
 - Modify Nepali orthography
 - Resolves: #586898

Only the very last change could have an impact, I don't think that's it though. What else could influence LibreOffice this way ?

I am starting to doubt this. Is it possible a fix in LibreOffice was backported to LibreOffice v4.3 and v4.2, and therefore impacted each of these releases in similar ways ?

I found this that seems related:

    https://bugs.documentfoundation.org/show_bug.cgi?id=84095

(In reply to Dag Wieers from comment #10)
> I am starting to doubt this. Is it possible a fix in LibreOffice was
> backported to LibreOffice v4.3 and v4.2, and therefore impacted each of
> these releases in similar ways ?

It's possible, however you said:

(In reply to Dag Wieers from comment #6)
> ...I have all LibreOffice versions from
> 3.5 to 4.4 on my system and only noticed it during the 4.4 development
> phase. But when I went back and tried it on older LibreOffice versions, I
> noticed what used to work isn't working anymore.

I took that to mean that you'd tested with something from the 3.5/3.6-era, and specific builds that used to work for you are now broken. If that's not what you meant, then please clarify so that we can get something solid and actionable documented for the developers.

(In reply to Robinson Tryon (qubit) from comment #11)
> I took that to mean that you'd tested with something from the 3.5/3.6-era,
> and specific builds that used to work for you are now broken. If that's not
> what you meant, then please clarify so that we can get something solid and
> actionable documented for the developers.

Dag: please reply to this. Setting to needinfo.

Btw. I recommend getting involved with Dutch LibO folks as they are organizing events: https://www.facebook.com/libreofficenl/ You could investigate this bug with them in such an event.

It is still not working. I test every release up to 5.3 now.

And I provided an example file that showcases the problem, so it is very easy to reproduce this problem. Look at the very first problem description for EXACT instructions to reproduce this yourself.

Yep, we don't need Helvetica Neue installed to see the weights get lost. I edit for example the sect0 paragraph style and observe the style turn to Regular on saving as .doc.

This already happens with 3.6, though.

Dag: looking at your CV, you would be a pretty bad-ass addition to the infrastructure team. So if you sometimes feel like helping out, you can check it out: https://wiki.documentfoundation.org/Category:Infrastructure http://salt-states-base.readthedocs.io/en/latest/

Tested with:

Arch Linux 64-bit, KDE Plasma 5
Version: 5.3.3.2
Build ID: 5.3.3-1
CPU Threads: 8; OS Version: Linux 4.10; UI Render: default; VCL: kde4; Layout Engine: new; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group

Arch Linux 64-bit
Version 3.6.7.2 (Build ID: e183d5b)

It's possible that my example fails on LibreOffice 3.6, but my workflow is different (we create the exact XML output) and that used to work find as the adornments were just part of the Font name. LibreOffice retained those.

When this didn't work anymore because adornments were additionally supported (differently) I moved to the new way of working, but LibreOffice did not retain this information when converting to DOC.

That is why it stopped working for me somewhere in between versions. But I never used the LibreOffice GUI for this until it started to fail.

Sorry for the confusion.

See my comment https://bugs.documentfoundation.org/show_bug.cgi?id=89491#c7 for the XML details on how it used to work, and why it started failing since 4.4

Before v4.4 adornments did not exist, it was all based on font names, which worked fine.

Dear Dag Wieers,

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 https://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://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug