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

[Dan Osipov]

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