Distribution content over pages completely different (since compared to older versions) since 6.4
Steps to Reproduce:
1. Open the attached file
2. Scroll to page 8
3. On top of the page should be 2 allow bullets (at least that the case in 6.0-6.2). Not a whole list
10-15 arrow bullets the start of page 8
2 arrow bullets
User Profile Reset: No
Found in 7.1
but not in
Created attachment 162939 [details]
Created attachment 162940 [details]
author Jan-Marek Glogowski <email@example.com> 2019-07-04 01:45:11 +0200
committer Jan-Marek Glogowski <firstname.lastname@example.org> 2019-07-05 19:38:01 +0200
commit 7dd44125a9c184c21374a47005e303579179805f (patch)
parent 4154d281fbecaadf6cd118c00cc6cff929e339a4 (diff)
WIN don't register LO's shared fonts twice
This separates the system registration (AddFontResourceEx) of
LO's shared fonts from the later PhysicalFontCollection
population using EnumFontFamiliesEx.
Calling AddTempDevFont from GetDevFontList creates a new
WinFontFaces, but the later EnumFontFamiliesEx also creates
WinFontFaces for all registered fonts, resulting in duplicate
WinFontFace entries in the PhysicalFontCollection.
Also currently the provided WinFontFace from AddTempDevFont is
much less accurate, compated to the EnumFontFamiliesEx one.
-> An additional confirming bibisect would be nice
If you have some time, would you mind to check the bibisect..
Note: Win only
Has probably something to do with Font Substitution
(In reply to Telesto from comment #3)
> If you have some time, would you mind to check the bibisect..
> Note: Win only
I don't understand the report. Please include a screenshot of good vs. bad result.
Bibisect result at least seems wrong, but maybe there is something that gives us a different result - maybe I am looking at the wrong page. Screenshots should help with that.
Created attachment 162972 [details]
Created attachment 162973 [details]
Clearly something with fonts.. first thought.. font substitution change.. but bibisect results in comment 2
Looking at the PDFs, I still don't understand what you mean. Please quote some lines and refer to the pages of the different PDFs.
(In reply to Buovjaga from comment #9)
> Looking at the PDFs, I still don't understand what you mean. Please quote
> some lines and refer to the pages of the different PDFs.
Side by side view helps
p9 export 6.2 is p8 7.1. And look at distribution of text/images & the font(size)etc..
(In reply to Telesto from comment #10)
> (In reply to Buovjaga from comment #9)
> > Looking at the PDFs, I still don't understand what you mean. Please quote
> > some lines and refer to the pages of the different PDFs.
> Side by side view helps
> p9 export 6.2 is p8 7.1. And look at distribution of text/images & the
From your description:
"On top of the page should be 2 allow bullets (at least that the case in 6.0-6.2). Not a whole list"
I understood that it was about *the same content*, but incorrectly having many more bullets.
I am bibisecting this with win32-6.2
win32-6.2 gives me
upgrade the internal harfbuzz to 1.8.4
Sounds plausible. Hard to say what is the exact issue that needs fixing here. I certainly have no idea what would be the preferred look. They both look messy to me.
(In reply to Buovjaga from comment #13)
> win32-6.2 gives me
> upgrade the internal harfbuzz to 1.8.4
> Sounds plausible. Hard to say what is the exact issue that needs fixing
> here. I certainly have no idea what would be the preferred look. They both
> look messy to me.
Hmm, lets focus on the source file, seems a better approach: attachment 134746 [details]
And this gets really interesting :-). The has with 6.2.9 an image called Görüntü11. The same image isn't present in 18.104.22.168.alpha0+.
One of many weird 'tracking changes' issues. For full list of bugs I created based on this file, see the see also of bug 134746 (source doc)
And no clue what you bibisected: I see no difference between 6.2 and 6.3..
So where surely on a different path :-)
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!