On September 13, 2010 12:41:08 pm Erik Krause wrote: > Am 13.09.2010 15:52, schrieb Yuval Levy: > > Processing PSD layers is the default behavior of most modern > > applications so why should the default for TIFF layers be different? > > Because these are no layers. Layers always have the same resolution and > bit depth. TIFF pages don't.
Indeed these are better than layers - they can function as layers, as previews, as alpha channels, as book pages, and many other things, some of which have not been thought of yet. > Gimp uses TIFF pages as layers, most other > programs use them to store preview images. Actually Gimp has its own file format, and it gives TIFF users access to many features of the TIFF formats, including pages (but sadly excluding color depth of more than 8 bits). When I open a TIFF document with multiple pages in Gimp, I can open them as layers of the same documents, or as separate documents, or just open one or a few of them. > Unfortunately this was a step back for most other users. Who are you to speak for "most other users"? Contributing users have had time to discuss the change when it was proposed, and have accepted it and learned to live with it. Functionality is extended, not broken. > > You have write access to the repo. Nobody prevents you from branching > > out and improving on 3.2 if you think so negatively of 4.0. > > You know very well that I'm not able to. All I can do is report bugs. > And probably you also know that I don't ask for myself. Be assured, I > always find a workaround if I need to. I'm asking because of my > droplets. It's annoying to always tell people that I can't help them > because their problem is a quirk in enfuse, enblend or one of the other > command line utilities. You're playing the same old boring tune. Pointing fingers all around, just not toward the NPP. Let me point it for you: the "quirk" is in your droplets. enfuse / enblend have moved forward, adding new functionality that was not possible with the previous way of handling TIFF files. It is your droplets who do not support them. Did you complain with Adobe when newer versions of Photoshop stopped supporting Windows 2000? It is relatively easy to add logic to your droplets to check if a file is a multi-page tiff. It is relatively easy to add logic to your droplets to extract specific pages from such tiffs. It is relatively easy to add a switch to your droplets to discard extra pages. It is difficult, not to say impossible, to overcome the command line length limitations of most operating systems supported by enblend-enfuse. That's another case in which the multi-page tiffs, and enblend-enfuse current behavior, come handy. > And it's even more annoying when I'm told here: "Improve yourself if you > want it" Nobody demands you improve yourself. You have been offered many workarounds/alternatives. You are the one who is never happy. You are the one who demand others to improve. By now most contributing users know your wish. Speaking for myself, I see the merits of your wish, and I think that it would be nice to have controls to deliberately address individual pages inside a TIFF file. IIRC an index like file.tif[N] with N being the indexed number of the page was discussed. But there are many other things on my "nice to have" list, and they are no reason to pull out the old record repeatedly. > or "Beta cycle is closed, you must live with what you got" when > I hadn't the chance to test because there was no windows build. Honestly, the only difference access to a windows binary during the beta cycle would have made is to give you a head start on the coming changes. Hint: There is more of a head start for you in the current documentation. Some command switches will be deprecated in the next release and if your droplets keep using those commands, they will likely stop working when version 4.1 is released. > Oh, well, I just tried one more time and I got the same answer as always. > Believe me, this doesn't encourage to contribute more. Sad... Telling others that there is a bug because they "have not thought a bit further" is encouraging feedback indeed. I wish it was the last time I heard your same old broken record, but something tells me this is a bug destined to remain on the wish-list with the mention "won't fix". > And, BTW, (because you mentioned it here): A high security password does > absolutely nothing to prevent spamming. Or do you think a spammer won't > be able to type such a password? Tell that to the tweets (pun intended) who've had their accounts hacked [0]. Once again, you seem not to understand the issue. The issue is not spammers typing passwords to open new accounts: best practice is to deal with this before the password is even created; and to impose certain limits/restrictions on new accounts. The issue is spammers hacking existing accounts. They will aim for "top" accounts (e.g. those who have the highest privilege / karma / reputation / followers / seniority / etc.) to abuse them and spam the whole system. But one again you see the world through your own NPP of what is "easier" for you and fail to consider other aspects. Yuv [0] http://www.google.com/hostednews/ap/article/ALeqM5hyKyasBy6f3XU_S1MeYyUCothiywD9I3TF2O0
signature.asc
Description: This is a digitally signed message part.
