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

[Uschi Renziehausen]

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

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

Again, I hope it makes sense what I have written ...

Uschi (who at times gets really confused with DAM)


> Dan Osipov
> Calkins Media
> http://danosipov.com/blog/
> 
> Uschi Renziehausen wrote:
>> Hi Dan,
>>
>> thanks for adding the two missing types in the first place.
>> I do have a question about the purpose of those media types concerning 
>> DAM.
>>
>> Looking at $TCA['tx_dam'], we find media_type defined as the type 
>> field. This is a means of control for the showItem part, that will 
>> offer usable forms to editors. 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 also wonder whether it is a wise move to create a new media type for 
>> psd. In the end, what you create with ps are images, only difference 
>> is that they are not for the web. But you want to insert meta data 
>> about resolution, width, height and so on.
>>
>> Why does DAM need the information whether or not a file needs a 
>> special software to open it? This is normally defined under Apache, 
>> correct? I hope you do understand my question.
>>
>> Kind regards, Uschi
>>
>> Dan Osipov wrote:
>>> Patch attached.
>>>
>>> Dan Osipov
>>> Calkins Media
>>> http://danosipov.com/blog/
>>>
>>> Dan Osipov wrote:
>>>> Team,
>>>>
>>>> This is a SVN patch request.
>>>> Branches: 1.1.0-dev (trunk)
>>>> BT Reference: http://bugs.typo3.org/view.php?id=9403
>>>>
>>>> Problem: DAM does not recognize common file types PSD and ODT.
>>>> The attached patch assigns ODT the application type (could be text, 
>>>> but since open office is required to view it, it would seem like 
>>>> application is more appropriate), and PSD a new "photoshop" type, 
>>>> complete with a special icon. Icons will be committed with the patch 
>>>> when it is approved.
>>>> One of the common mime types was selected - IMHO it doesn't matter, 
>>>> as its not used for anything functional - just choosing a display type.
>>>>