<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <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#c67">Comment # 67</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:lukebenes@hotmail.com" title="Luke <lukebenes@hotmail.com>"> Luke</a> <pre>(In reply to Yousuf Philips (jay) from <a href="show_bug.cgi?id=34133#c66">comment #66</a>) > 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, Most Users? Home users sure. But if want to be taken seriously by professionals, we should act like professional software and not assume the user is stupid and doesn't care about quality. The professionals I work with care very much. They calibrate their monitors and send their work to professional printers. Your line of thinking turns that kind of user off, ensuring we remain a toy for hobbyists. > and those who do notice it will easily > be able to fix it. We are talking about DESTRUCTIVE EDITS. This assumption that it can just be "fixed", is only true if the user still has access to the original, notices it, and it aware of this backwards workflow. If users are familiar with other Office or professional software, they will not be expecting this behavior. > 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. Have you ever worked with printed material? Images can look fine on the screen, but suffer from noticeable compression when printed. Nevermind the fact we shouldn't be reapplying lossy compression without the user requesting it. > 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>). Trick unsuspecting users into using low quality images instead of fixing our rendering system is a terrible idea. I'd much rather have slow downs then have the quality of my work degraded to hide some performance bug. > We are well aware of this issue, and many others, and Tomaz is already > taking such a scenario into consideration with his development work. I understand the argument for defaulting to 222 DPI unless resizing is disabled. This is how Word works and is acceptable, especially when done at save time. However, compression is another story. Word does not recompress images implicitly. JPEG compression is lossy. Every Time you compress a compressed image you lose quality. This is why this option should be explicit for all users. For example if I insert a 69% image and LO again recompressed at 90%, the only thing accomplished is LOSS OF IMAGE QUALITY. > 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. Of the 22 people here that want this feature, 3 have already spoken out that the design meeting proposed approach was flawed. This was done within hours of Heiko's announcement. Hopefully this is being communicated. In summary, Professional Software does not performs destructive edits at insert time. This feature is going to annoy profession users who discover it after the fact. It will lead to data loss for home users who do not have access to the original. The proposed implementation comes with all of these serious negatives for 2 very weak advantages.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>