<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body><a class="email" href="mailto:philipz85@hotmail.com" title="Yousuf Philips (jay) <philipz85@hotmail.com>"> Yousuf Philips (jay)</a> changed <a class="bz_bug_link bz_status_NEW " title="NEW - Add ability to automatically compress and resize images" href="https://bugs.documentfoundation.org/show_bug.cgi?id=34133">bug 34133</a> <table border="1" cellspacing="0" cellpadding="8"> <tr> <th>What</th> <th>Removed</th> <th>Added</th> </tr> <tr> <td style="text-align:right;">CC</td> <td> </td> <td>rb.henschel@t-online.de, vstuart.foote@utsa.edu </td> </tr></table> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Add ability to automatically compress and resize images" href="https://bugs.documentfoundation.org/show_bug.cgi?id=34133#c66">Comment # 66</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Add ability to automatically compress and resize images" href="https://bugs.documentfoundation.org/show_bug.cgi?id=34133">bug 34133</a> from <a class="email" href="mailto:philipz85@hotmail.com" title="Yousuf Philips (jay) <philipz85@hotmail.com>"> Yousuf Philips (jay)</a> <pre>(In reply to Luke from <a href="show_bug.cgi?id=34133#c65">comment #65</a>) > The trend in UIs are for people to drag and drop. Putting a pop-up dialog up > every time a user drops an image interrupts the work flow. No there wouldnt be a popup for drag and drop or copy and paste, so whatever optimization setting that has been configured at document-level will automatically happen. > People don't want > to have to think about compression settings at insert time and often don't > know their target. This is a disadvantage, because you will either have > unintentional data loss or an annoying pop-up to close every time you insert > things. Most users will never disable the compression settings, but for those that care to disable it, they have easy access to do so at the document-level in the insert image dialog. Most users wont visually be able to see the difference between the original image and the optimized image due to the nature of jpg compression technology, and those who do notice it will easily be able to fix it. > In a world of 4 TB hard drives and 32 GB of RAM this "advantage" rings > hallow. As the developers point out, the problem in <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED DUPLICATE - Editing very slow with big picture on page" href="show_bug.cgi?id=78529">Bug 78529</a> is with out > image caching. Once that's fixed, this won't be an issue. I'd rather deal > with any performance issues than produce low quality output. Not everyone lives in such first-world luxury of having endless amounts of hard disk space, memory and lets not forget CPU power, and even if one does, why produce a 31 MB document with original images[1], when a 4 MB document with optimized images[2] is close to identical in quality. [1] <a href="https://drive.google.com/file/d/0B6qJrVIa0SAlVHpOZFV3QUdmRjQ/view?usp=sharing">https://drive.google.com/file/d/0B6qJrVIa0SAlVHpOZFV3QUdmRjQ/view?usp=sharing</a> [2] <a href="https://drive.google.com/file/d/0B6qJrVIa0SAlX3BJZWlfdGs2eDg/view?usp=sharing">https://drive.google.com/file/d/0B6qJrVIa0SAlX3BJZWlfdGs2eDg/view?usp=sharing</a> I wont hold my breath for when <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED DUPLICATE - Editing very slow with big picture on page" href="show_bug.cgi?id=78529">bug 78529</a> gets resolved, as it is a known issue that has been around for 5+ years (<a class="bz_bug_link bz_status_NEW " title="NEW - [meta] image caching / management is utterly shambolic" href="show_bug.cgi?id=47148">bug 47148</a>) and likely will still be around for many years to come. Here is another example of images slowing down the UI (<a class="bz_bug_link bz_status_NEW " title="NEW - File with many images takes a long time to open and save" href="show_bug.cgi?id=100442">bug 100442</a>). > Every application that I have ever used that allows for compressed images > puts destructive edits as an explicit, manual operation or at save time. If > these are the only advantages you can think up, than the disadvantages far > out-weight the advantages. Guess we'll agree to disagree. > Heiko Tietze said the default compression will be 90%. Didnt see him saying that anywhere, <a href="show_bug.cgi?id=34133#c37">comment 37</a> is minutes from a design meeting, and we are still researching what the most optimal compression will be from 80 to 95 percent. > So what if we insert already highly compressed images? Will this compress > them again? With lossy compression, this will do nothing but result in a > lower quality image. This is just another reason why this idea needs to be > thought thought more carefully. We are well aware of this issue, and many others, and Tomaz is already taking such a scenario into consideration with his development work. Development of this feature and workflow is already underway with input from the design team, so for those who still wish to debate this further, please attend one of the design meetings that happen on Thursday's at 11am UTC. For those interested in helping ensure the feature works correctly, please submit sample documents with images that you think should or shouldnt be optimized along with the reasons, or suggest scenarios that should be taken into account.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>