[TYPO3-dam-devel] RFC #9403: Missing media types: psd and odt

[Uschi Renziehausen]

Dan Osipov wrote:
> OK, the only problem I see with that is that DAM tries to create a 
> thumbnail, which it can't for PSDs... This results in an ugly question 
> mark.
> 
> If that's OK with you, I'll work on redoing the patch, adding all the 
> other type mentioned.
> 

I am perfectly alright with that :-)

The day will come, where we have nice and shiny icons for DAM, I am sure.

Thanks, Uschi

> Dan Osipov
> Calkins Media
> http://danosipov.com/blog/
> 
> Uschi Renziehausen wrote:
>> Hi Dan (and the rest),
>>
>> the psd as own media type has my -1.
>>
>> I have asked 5 normal editors now, all of them knew what photoshop is, 
>> so we do not have any report from those who do not. They all would 
>> expect their psd files show up under image (when making selections).
>> Same counts for Corel Draw users and cdr, I guess.
>>
>> Also, when we have an own media type for psd, it gets a prominance it 
>> simply does not deserve, and if we do it your way for 1.1 and find 
>> another solution for 1.2 people will have to update their databases 
>> manually, even those who start dam project from scratch.
>>
>> The last point is a problem anyway: I had uploaded some odt files 
>> before I applied your patch.
>>
>> And *sigh* I found even more important file endings missing, noting 
>> them down here (should we open up a wiki page at forge for that stuff, 
>> so that we can collect them in an orderly manner?)
>>
>> .svg
>> .xcf (Gimp)
>> . odt and otf is there now, but the whole rest is missing (for calc, 
>> draw and so on)
>>
>> Uschi
>>
>> Dan Osipov wrote:
>>> See below. I think this is a patch, rather than a feature, and we can 
>>> rework this soon for 1.2, once we get 1.1 out the door (long overdue)...
>>>
>>> Dan Osipov
>>> Calkins Media
>>> http://danosipov.com/blog/
>>>
>>> Uschi Renziehausen wrote:
>>>> Hi Dan,
>>>>
>>>> first a big thanks for the patch, but I think we need to discuss 
>>>> this bit a little more.
>>>>
>>>>
>>>> Dan Osipov wrote:
>>>>> Question understood. Here is my thinking:
>>>>>
>>>>>  > Now, for type text we can get rid of all the stuff we
>>>>>  > need for images. From this point of view I would prefer to see .odt
>>>>>  > under text, where we find .doc btw.
>>>>>
>>>>> I thought text files were automatically available for editing with 
>>>>> the internal editor, but after testing, apparently its not true. 
>>>>> Which way we declare odt type doesn't really matter to me, but I 
>>>>> agree that it should be kept consistent - so if we keep it as 
>>>>> application, I would move doc to be application as well.
>>>>>
>>>>
>>>> I prefer the other way round: move sxw,odt and the like under 
>>>> media_type text. Reasons:
>>>> 1) Other than the mime type, the media type in DAM is primarily 
>>>> intended to be a means a human oriented categorization of files, so 
>>>> it is a helper for ordinary authors to find media items and they 
>>>> will think of doc and odt as text and not as application. That this 
>>>> is the primary intention of media_type is stated in the current 
>>>> docs, see chapter Mime types and media types.
>>>>
>>>> 2) In $TCA the field media_type is defined as the type field, so it 
>>>> is our means to decide which fields are shown in BE. A psd file has 
>>>> width and length, odt, doc, pdf have e.g. pages, while videos and 
>>>> audios have a playlength and so on.
>>>>
>>>> 3) In future versions of DAM we might also want to have versions of 
>>>> a file (a text might exist as doc,pdf, and odt, all sharing stuff 
>>>> like title, abstract, keywords, categories). An image might be 
>>>> available as psd, tiff, jpeg and so on.
>>>
>>> I see your point. I'll modify them to be text.
>>>
>>>>
>>>>>  > I also wonder whether it is a wise move to create a new media 
>>>>> type for
>>>>>  > psd.
>>>>>
>>>>> Yes, it needs metadata, but it can't be pulled using the same 
>>>>> methods as for JPG images (IPTC/EXIF, etc). It is my understanding, 
>>>>> that using the separate type, services could be created to pull 
>>>>> this metadata.
>>>>
>>>> I do not think that we need a special media_type just because we 
>>>> need a new service. Take doc as an example: There is a special 
>>>> service for it, but the media_type is text. Same counts for PDF and 
>>>> AI, the latter categorized as image.
>>>
>>> AI is manually set up as an image in the dam_types file (otherwise it 
>>> would have been an application). Another type for PSD adds an icon, 
>>> and makes it easily distinguishable from other images in the file and 
>>> list menus. I am for adding PDF and AI icons as well, but those are 
>>> separate.
>>>
>>> Maybe in 1.2 we can rework the way icons are assigned to files, by 
>>> the MIME type, rather than the artificial selection?
>>>
>>>>
>>>>> Also, psd is not truly an image, as it can't be rendered in web 
>>>>> browser, or processed by IM (?). Declaring it as a new media type 
>>>>> also gives it a special icon - so that it is separated from other 
>>>>> files in the list - I would even argue for using special icons for 
>>>>> all files in the future.
>>>>>
>>>>>  > Why does DAM need the information whether or not a file needs a 
>>>>> special
>>>>>  > software to open it?
>>>>>
>>>>> If a file is declared as an image, the info module changes 
>>>>> dramatically. Thumbnail is rendered, options change, etc. Each 
>>>>> media type gets its own info module. I think that's the only reason 
>>>>> for the 12 - now 13 - types.
>>>>>
>>>> cdr, bmp, tiff are all under image, and they cannot be rendered by 
>>>> the browsers.
>>>
>>> BMP can be rendered, and maybe TIFF (not sure on this one). But I'm 
>>> for moving cdr to application type.
>>>
>>>>
>>>> Again, I hope it makes sense what I have written ...
>>>>
>>>> Uschi (who at times gets really confused with DAM)
>>>>
>>>>