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

[Uschi Renziehausen]

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)
>>
>>