| Summary: | UI: Being able use the option 'Save' Image without conversion | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Telesto <telesto> |
| Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | NEW --- | ||
| Severity: | enhancement | CC: | buzea.bogdan, heiko.tietze, quikee, vsfoote |
| Priority: | medium | ||
| Version: | 7.2.0.0.alpha0+ | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 103152 | ||
| Attachments: | Example file | ||
|
Description
Telesto
2020-12-11 22:57:39 UTC
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.. |