To me the most important is optimice the PNG output. You can archive "similar" sizes than JPG with optimizations.
Current trunk have special options to export. This is cool but not too useful to most of users dont undertand the options inside.
Im thinking in a way to integrate something like https://pngquant.org/ with a one slider "Quality"
Cheers, Jabier.
On Fri, 2017-02-17 at 14:49 -0800, Bryce Harrington wrote:
On Fri, Feb 17, 2017 at 11:17:27AM -0500, Martin Owens wrote:
On Fri, 2017-02-17 at 18:51 +0300, Alexandre Prokoudine wrote:
A job for https://developer.gnome.org/gtk3/stable/GtkInfoBar.html maybe?
I have an outstanding wishlist item for the InfoBar. :-( A generic implementation would be a useful first step.
On Fri, 2017-02-17 at 16:42 +0300, Alexandre Prokoudine wrote:
- is not color management aware
- only support 8-bit data per color channel max
- only handles RGB(A) and greyscale images
That sounds like what we want.
On Fri, 2017-02-17 at 15:26 +0000, C R wrote:
could say "File size as png: 20kb" Then a button or link below it that says "Save as .png instead".
We'd have to generate a png before we knew how big it would be. We could guess I guess. But that's more complexity.
On Fri, 2017-02-17 at 13:43 +0000, John Cliff wrote:
JPEG export was in the codebase about 5 years ago, I just never got round to writing the file dialogue for it. Had a right click export to JPEG option setup that was ifdef'd out of I recall rightly (it's been a while!)
So it's an easy addition to detect jpeg/jpg ending in the png export and save to jpeg instead? First draft doesn't need a file dialog or a quality slider or anything like that, just output the file.
I get the feeling that as Bryce said, when you add a thing, people then come looking for the thing+1 and the thing+5 and before you know it you have hundreds of thousands of open bug reports.
Sometimes this phenomenon is a good thing and the annoying grousing actually leads us to valuable improvements and increases Inkscape's power for users. Inkscape's PDF export is my go-to example for how this growth-through-pain mechanism can work to our benefit.
Other times the phenomenon just leads to scope creep and not in a good way. I'll just cite Zawinski's Law here as example. ;-)
Regarding jpeg output specifically, this has been considered multiple times in the past, but the consensus folks generally came to was that it should be outside the scope for Inkscape. It's not a good format for the type of graphics Inkscape produces, and while there are sites and services that take only JPG files, it seems kind of a lazy convenience - there's plenty of good tools out there for converting PNGs to JPGs; if it's inconvenient to have to do that, and makes people wonder if they're doing something wrong, well that's not necessarily a bad thing... ;- )
That said, I don't think fundamentally or technically it would be impossible to include jpeg support*. From what I've read, developers would be open to it, but would want to see more compelling reasons than have been seen. Perhaps this would be a good topic to solicit further user input on.
Bryce
- -- if anyone does get a motivation to work on this, I'd strongly
encourage doing it in a branch so we can ensure the functionality is fully baked before it appears in trunk.
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel