In the following document (16Mb) -
If you open it and click the PDF button (images saving losslessly) to save it numerous times in a row (each time overwriting the last), each time checking the resulting file size, the resulting PDF sizes are hugely erratic.
Something is not right :)
Steps to Reproduce:
Open file, save as PDF several times noting resulting PDF sizes
A fixed size roughly the size of the document
User Profile Reset: No
Version: 22.214.171.124 (x64)
Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1
CPU threads: 2; OS: Windows 10.0; UI render: default;
Locale: en-GB (en_GB); Calc: group threaded
Created attachment 144646 [details]
Result of export to PDF
don't repro in
Версия: 126.96.36.199 (x64)
ID сборки: 2718b4a18dfcc6a54ebe5f7b801ee7a47fa81e0c
Потоков ЦП: 4; ОС:Windows 10.0; Отрисовка ИП: по умолчанию;
Локаль: ru-RU (ru_RU); Calc: CL
Created attachment 145141 [details]
Document with the problem
Tried 4 times, but size is always 8,6 MiB
Maybe try using LibreOffice in Safe mode, Help - Restart in safe mode and then Continue in safe mode (or launch from the Windows Start menu entry)
Set to NEEDINFO.
Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.
Arch Linux 64-bit
Build ID: 8b1501d80dc9d3f42c351c6e026fa737e116cae5
CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5;
Locale: fi-FI (fi_FI.UTF-8); Calc: threaded
Built on 23 September 2018
This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INSUFFICIENTDATA
due to lack of needed information.
For more information about our NEEDINFO policy please read the
wiki located here:
If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
Thank you for helping us make LibreOffice even better for everyone!
Please read this message in its entirety before proceeding.
Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):
a) Provide details of your system including your operating
system and the latest version of LibreOffice that you have
confirmed the bug to be present
b) Provide easy to reproduce steps – the simpler the better
c) Provide any test case(s) which will help us confirm the problem
d) Provide screenshots of the problem if you think it might help
e) Read all comments and provide any requested information
Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:
a) respond via email
b) update the version field in the bug or any of the other details
on the top section of our bug tracker
Hi, there are no reproducible steps I can give because it is an erratic bug, but it happens frequently, and has just happened in the document I've just saved. My first PDF was over 300 Mb, I saved again and it was 30 Mb. As you'll have seen in my initial comments, precisely the same sequence of actions will produce different outcomes.
I think you need to recognise that there are a good many very serious erratic bugs in LibreOffice for which no reproducible steps can be given, yet which occur regularly, and closing such bugs is very unhelpful: what's needed is a status that you can set that marks it as a serious but erratic so that it can be kept a watch for and in mind as people constantly work on the code.
As to the system it's just occurred on, it is -
Version: 188.8.131.52 (x64)
Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c
CPU threads: 2; OS: Windows 10.0; UI render: default; VCL: win;
Locale: en-GB (en_GB); UI-Language: en-GB
I can say that the PDF is more likely to come out correctly after closing and opening the program and exporting it with no action on the file, and that even a slight edit of a single word before exporting may cause the PDF to be 300Mb rather than 30Mb. But equally it may not.
I guess some script could be created that saves over and over again and monitors the resulting file size
What would really help with tracking such bugs as these - and in fact most bugs - would be to have a 'recorder' feature on LibreOffice, that a user having a problem can switch on so that it makes a copy of the file and then records all the actions and steps they make, and when a problem occurs they can send you the file that was opened with the action record that then happened to it, which may be 500 actions, but it may have been the 10th action of the 500 that generated the problem, the programmers could step through and watch for it to happen using a halving method (apply the first 250 steps to see if the problem was caused, then 125 steps to the side of that (i.e. 125 or 375 steps) etc, then 63, 31, 15 etc) which would quickly catch how just about every problem occurred.
(In reply to DM from comment #9)
> What would really help with tracking such bugs as these - and in fact most
> bugs - would be to have a 'recorder' feature on LibreOffice
There actually is such a thing: https://wiki.documentfoundation.org/Development/UITests#Tools_for_writing_a_test
But I'm not sure if it would help in this case, if the command sequence is the same all the time.
Well I gave in my comment 2018-09-01 15:45:41 a file which was 'reproducible' i.e. when opened it saved as erratic sizes, and I recall others were having the problem. Obviously not everyone found the same result. I should probably see what that file now does on the current version, but clearly the basic problem still exists.
The general problem I have is that serious bugs get closed merely because it's hard to reproduce an issue, as if closing a bug somehow made it go away. They need to stay alive in some way in order to be watched out for, because programmers will notice things as they program if they have in mind a list of serious bugs that can't be reproduced. I do find LibreOffice constantly mangles up the contents of so many of my files, typically ones involving tables with pictures and drawing items in, but I do persist with it because I need to be able to use the lossless PDF export, and I hope these serious bugs may get sorted as it's a good project.
Created attachment 156291 [details]
Unusual but consistent size
On a related note, the attached document is 9047 K but saves seemingly consistently as a PDF (set to lossless images) as 13666 K.
Generally I find a lossless save (when it doesn't suffer from the vast random bloatation mentioned in the thread) is roughly the size of the PDF, so this is an anomaly, one I've noticed before on a few documents.
This occurs on the latest beta as well as 6.3.x.
(Now the random PDF blotation mentioned in the thread I will check out for on the 6.4 line. I've been circumventing that issue by closing libreoffice and reopening afresh which usually results in a PDF size similar to the ODT rather than eg 10x the size, but it's best to be able to export to PDF without having to close and reopen.)
Version: 184.108.40.206.beta1 (x64)
Build ID: 4d7e5b0c40ed843384704eca3ce21981d4e98920
CPU threads: 2; OS: Windows 10.0 Build 18362; UI render: default; VCL: win;
Locale: en-GB (en_GB); UI-Language: en-GB
Looks like I reproduced different sizes for lossless export without reduce resolution. Lo 6.5+.
Sizes were: 16 MB, 161, 147, 128, 147.
With Reduce resolution set to 300, I had the same size of 78 MB.
With Jpg compression 90%, I had the same size od 16 MB.
With Lo 6.0, all sizes are same, 16 MB. So as reported, seems started from 6.1.
I am thinking from the 16Mb reference you could be referring to the original example in Comment 1 (in contrast to Comment 12)
Yes, I just tested the example from comment 1.
I previously tested attachment 145141 [details] from comment 1 in Windows and reproduced from 6.1.
I now tested in Linux. It's mostly 13,7 MB on 1st export but size is erratic if repeated few times (on 2nd or 3rd or 4th). So best to try 5 times.
Question: can we set images resolution in PDF export headless mode?
If not, that's a good candidate for a new bug.
3b744b816e7f6291eb9e4bf87b6d920f8cd35ecb is the first bad commit
Author: Jenkins Build User <firstname.lastname@example.org>
Date: Tue May 8 02:30:57 2018 +0200
commit 1b2ea80a9faf52e9b1b6312a25e646674425ef0f (HEAD, refs/bisect/good-1b2ea80a9faf52e9b1b6312a25e646674425ef0f)
Author: Jenkins Build User <email@example.com>
Date: Tue May 8 02:07:23 2018 +0200
commit c6cf2320d2a464594e759289c34796538d31f02b [log]
author Tomaž Vajngerl <firstname.lastname@example.org> Fri Apr 27 18:30:45 2018 +0900
committer Tomaž Vajngerl <email@example.com> Tue May 08 02:25:14 2018 +0200
parent ecf50fe71596c3edba8ce437481ab80ae1cd8935 [diff]
config entries for the new graphic manager, deprecate old entries
Add 2 new GraphicManager config entries GraphicMemoryLimit and
GraphicAllowedIdleTime. At the same time, deprecate the existing
config entries used in GraphicObject's GraphicManager, which are
not relevant anymore.
Tested-by: Jenkins <firstname.lastname@example.org>
Reviewed-by: Tomaž Vajngerl <email@example.com>