On 9/1/14 3:25 AM, Mark Crutch wrote:
You want JPEG export. I know others that would like Photoshop PSD files. Yet others will want TIFF, or BMP or other esoteric formats. Should Inkscape support them all, or would it be better to export one or two formats and allow the user to use another application to convert to whatever they want?You missed my point, Mark. Moving to another application to do the conversion takes time. I want to minimize the time I spend, not spend the extra time.No, I got your point. A few extra seconds and another application to convert is too much, so you want JPEG export built in.
Reality? This is no different than wanting a different feature in a car you buy, or on your smartphone, or on your TV. Why should it be different for software? And you've acknowledged that others would like other formats, so it's not like I'm the lone voice in the woods.
*My* point was: if we accept that a few extra seconds and another application is too much for you, we also have to accept that it's too much for the people that want PSD, TIFF or BMP export built in (and I've known people to want all of these, for one reason or another).
Exactly. Which is one route to product improvement, if you want to improve it. I think the "UNIX" philosophy will prevent any software created to become a leader and success. Providing things users want, whether developers want it or not, is what it takes to be successful. Otherwise, it's just a hobby. The philosophy may be the biggest impediment to being seriously considered by the majority of computer users, and why the software created under the philosophy will never seriously put a dent in commercial software.
I'm not against JPEG export from Inkscape if someone wants to contribute the code, but I think you're making it out to be a bigger deal than it really is. Converting doesn't have to mean loading a full-on editing application like Photoshop or The GIMP - there are lightweight applications that require little more than right clicking on the file and selecting "Convert to JPEG". Is that really so hard?
Converting is doing work on something already created. Until you actually create it, there's nothing to convert. If you look at the export process as conversion, then you are converting twice. One thing I hate doing, is the same damn thing twice. LOL
Drawing the line is always a tough question? If it were my call, I'd look at what's being used in the way of hardware/operating systems. With the plethora of XP users that are still out there, and seemingly in no hurry to upgrade, if the file format was available when XP came out, that's where I'd draw the line. Nothing directly supported for older systems.When XP came out, eh? That's 2001. The PNG format has been around since 1996, so that already meets your requirements. Better be careful with JPEG though, there are parts of the spec that have only been finalised since then (http://en.wikipedia.org/wiki/Joint_Photographic_Experts_Group#Published_Stan...).
Standards will always be a moving target. There's no way around that. But from what I see, JPG is currently the most popular bitmapped format. Not PNG. Granted, PNG has some advantages, but are the advantages needed by most users? I'd bet not. Just like a Kenworth has advantages over a Ford F-150, not everyone needs a Kenworth. <G>
Someone in this thread mentioned changing the dialogue from "Export Bitmap" to "Export PNG". If Inkscape .48 said that, we likely would not be having this discussion. The phrase "Export Bitmap" leads to the expectation of more than one type of bitmap file format was available. I know I did. Another user expressed his memory of being told years ago that other formats would be added.
Yes, I'm being a little facetious, but it's worth clarifying that "JPEG" isn't a single spec that was set in stone many years ago - it's a series of formats that's been refined and extended over the years. The same for PNG and many other formats. So if Inkscape gets JPEG export, is it allowed to use any of the more recent extensions to the standard? Or would you prefer it to stick to just pre-2001 features, just to be on the safe side?
It always should be upgraded to support the latest standard. All graphics programs, for the most part, have been upgraded to support it. Heck, programs had to add it when the first version of JPG came out.
If I wanted pre-2001 formats supported, I'd be asking for GEM, IMG, and others I've now forgotten about. <G> Hmmm, can't remember what the old Degas file format was.
But now you risk pi$$ing off your users who have an unknown number of files they've created, may want to use again, but can't? I think a classy organization would provide a separate program to convert the older files to a newer file so the user still has access to his/her older files. This may be easier for word processors than graphics software.You seem to have jumped tracks to the supported formats for *import*. I'm not really sure what that paragraph has to do with the rest of the conversation, but suffice to say that it's a damned good argument for using open file formats (such as PNG, SVG and ODF... and yes, JPEG - although there have been patent concerns around it over the years).
I kinda did, didn't I? LOL When wrote that, I was thinking of older JPGs, SVGs, etc. where the file formats have changed, and now you have no access to the older file that, while you may not want to edit the older file, you want to combine it with additional material.
I would actually argue that it's (usually) easier to convert old graphics to new formats than to do the same for word processor documents. Older bitmap formats are pretty straightforward and easy to convert. Older vector formats are less so, as they can be rather complex, but they're still not as bad as the "binary memory dump" that is the .DOC format. It's simply that there's been more work put into converting .DOC than (for example) .CDR files.
I'd agree on the comparison of word processor files to graphics files conversions. Even MS has the occasional problem there, from what I've read. I've got a lot of CDR files I'd like to convert sometime, but I'm looking for a GUI program to do it. Uniconvertor is supposed to support it, but I just don't like doing command line stuff anymore. No more often than I'd use it, I'd have to look up the instructions of what I needed to type to get the job done. If I'd get off my butt and install a battery holder, I'd have a running Compaq w/ Tabworx, and a copy of Corel Draw 4 I could install. Then I'd have another old computer to add to the collection. LOL
If a DTP program doesn't support a bitmap format with alpha channels then I *do* consider it broken as it prevents you from doing a lot of basic things, like putting a logo over an image. It doesn't have to be PNG, but in practice that's pretty much the only widespread open format that does the job.We sure define the word "broken" differently. <G> Bedda define the "basics" then. Because, before there was transparency, "basics" wouldn't include that ability.There's been transparency of one sort or another for a mighty long time. Before PNG, and before GIF's one-bit transparency, even. Heck, if you want to go back far enough we were engraving images into plates of metal, coating them in ink, and pressing them onto the page. And you know what... they included transparency! Any part where the ink didn't appear was implicitly transparent.
But, how much was transparency supported in computer software?
I guess I'm just accepting that it's 2014 and there are plenty of free (and Free) applications (and commercial ones) that support things like transparency, and will run even on an old Windows XP box. Given that, there's no particularly good reason why we should continue to pretend we're in the year 1985 (or even 2001) and we can't have transparency or any of the other nice goodies that have come along in the intervening years.
I never said you can't have it. It's just not always necessary.
If just about all of your competitors - even the free ones - support a feature, then I would definitely consider your software to be "broken" if you don't support it.
To me, broken is something that doesn't work, not something that's missing.
From my dictionary program:
broken |ˈbrōkən| past participle of break adjective 1 having been fractured or damaged and no longer in one piece or in working order
Something that is not working, not something that is missing. :-)
Anyway, this part of the discussion is relatively pointless, because it's already been shown that the software in question *does* support PNG and *does* support transparency.
So we're back to two real points to your argument:
- PNG files can be big
- Converting takes time
(1) is a valid argument for wanting JPEGs, provided you're happy to have a lossy format with no transparency support. I have no issue with that.
The needs of the end product/project would control whether the lossy format and/or no transparency makes any difference.
(2) does take time, but it can be kept down just a couple of mouse clicks and a few seconds per image. Not significantly longer than Inkscape would take doing the same thing. So where's the sense in the Inkscape developers spending time implementing JPEG support rather than working on the core code instead?
As .48 is now, it's the goodwill of providing users with what they are looking for, and not just what developers/contributors want to provide. That difference is one of the reasons I read quite often why things like Libre Office will never give Office a run for its money. Unless MS goes totally to cloud only operations, and no desktop versions, IMO. If that happens, I see little practical difference to the "olden" days of dumb terminals and no control over your own hardware.