Description: UI: Being able use the option 'Save' Image without conversion Steps to Reproduce: 1. Open the attached file 2. Right click the image & press Save 3. Save dialog appears, showing the proper extensions (based on source file type) 4. Put file name in it and press Save 5. Options dialog appears Actual Results: It appears to me LibreOffice is re-compressing on save Expected Results: As JPG is loosely format.. this ends up in unneeded quality loss. So it would be nice if there is a possibility make a choice between direct save or recompress. Yes, you can get to the 'source file' by extracting the zip.. A browser isn't reprocessing if you choose save image.. so this maybe kind of confusing. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.alpha0+ (x64) Build ID: 796c7f612603490dda9277ced0f6ab3cce3bc116 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Created attachment 168085 [details] Example file
The source image is held in ODF archive, and is parsed to identify the image type. Wouldn't a direct extraction of the image from archive, bypassing the Save dialog's conversion, be the use case?
(In reply to V Stuart Foote from comment #2) > The source image is held in ODF archive, and is parsed to identify the image > type. > > Wouldn't a direct extraction of the image from archive, bypassing the Save > dialog's conversion, be the use case? Yes -- More specific. I would be inclined to interpret "save" as store (as loseless). I tend to see current implementation actually as export behaviour (depending of file format). Even svg imaged are transformed (and save currently even break things) Extracting is the zip is not that conveniened.. not user friendly and kind of technical.. Also not everybody is aware of impact of reconversion. Or needing that. And currently jpg export dialog not working properly (but that's more short sighted argument (on state of instead of the long term vision). Pain point especially dpi suggestion based on screen resolution. But in any case still reconversion..
(In reply to Telesto from comment #3) > More specific. I would be inclined to interpret "save" as store (as > loseless). I tend to see current implementation actually as export behaviour > (depending of file format). Even svg imaged are transformed (and save > currently even break things) Agreed. Save should not be Export.
(In reply to Telesto from comment #3) > (In reply to V Stuart Foote from comment #2) > > The source image is held in ODF archive, and is parsed to identify the image > > type. > > > > Wouldn't a direct extraction of the image from archive, bypassing the Save > > dialog's conversion, be the use case? > > Yes > > -- > More specific. I would be inclined to interpret "save" as store (as > loseless). I tend to see current implementation actually as export behaviour > (depending of file format). Even svg imaged are transformed (and save > currently even break things) > > Extracting is the zip is not that conveniened.. not user friendly and kind > of technical.. Also not everybody is aware of impact of reconversion. Or > needing that. > > And currently jpg export dialog not working properly (but that's more short > sighted argument (on state of instead of the long term vision). Pain point > especially dpi suggestion based on screen resolution. But in any case still > reconversion.. (In reply to Heiko Tietze from comment #4) > (In reply to Telesto from comment #3) > > More specific. I would be inclined to interpret "save" as store (as > > loseless). I tend to see current implementation actually as export behaviour > > (depending of file format). Even svg imaged are transformed (and save > > currently even break things) > > Agreed. Save should not be Export. Meaning, that we need a new dedicated UNO action to extract the image from ODF archive unchanged to os file system -- i.e. to "Save"; and the current "Save" gets labeled "Save-as" or "Export"? Works for me but some will complain of cluttering the context menu, +1
I don't know about uno commands so can't help here=>uncc myself.
(In reply to V Stuart Foote from comment #5) > Meaning, that we need a new dedicated UNO action to extract the image from > ODF archive unchanged to os file system -- i.e. to "Save"; and the current > "Save" gets labeled "Save-as" or "Export"? > > Works for me but some will complain of cluttering the context menu, +1 Tendency to remove export. However, I have also reported bug 138836. So not quite sure how to argue me out of this :P. I'm able advocate why this being reasonable ;-) Other alternative would be to place compress, save, export into a submenu (maybe also crop/edit external). However, it's more clumsy an takes the speed away. Kind of hard with telemetry :-( Even considering the dynamic thing (Word XP?). So based on user behaviour. Where depends on how often something is used.. But flopped pretty badly.. if I recall correctly so.. There always the option to modify it yourself if you dislike the default, so
FWIW: what happens if 'Save image" would actually store the image instead of calling export in the case of an pasted image. This type shows 'unknown format' in compress dialog..