[TYPO3-core] RFC #11177: Feature: New options noRescale and resolutionFactor for getImgResource()

[Ries van Twisk]

On May 25, 2009, at 8:36 AM, Franz Koch wrote:

> Hi Ries,
>
>> I did read the whole thread and I see what the intention is now.
>>
>> If a DPI is specified, how would you specify the width and the height
>> (in inch or cm)
>> for images then??
>> Currently TYPO3 'supports' only image sizes in pixels. I can imagine
>> that 'some' calculation
>> can be done 'assuming' a Screen DPI is 72 or 96 DPI. But maby  
>> stefan can
>> explain
>> how the calculations work internally?
>
> I think it's calculated based on 72 and the defined image dimensions  
> in
> px. It's not perfect, but as a first step suitable for PDFs etc.
> (although not prepress ready)





>
>> Further...
>> A DPI setting makes only sense if you can specify correct width and
>> height for a image (IMHO).
>
> right - and thats one thing I'm not sure about how it could be handled
> best. Typo3 would have to support different measuring units (cm, inch,
> px, % for flexible layouts). And as you mentioned below support for  
> some
> kind of colormanagement would be needed for a perfect solution.

Hey Frans,

if this is the case I could almost think of a global config setting  
rather
then a local on given for each images (rather then using  
xxxxx.file.resolution = 200).

// set images to render at higher resolution
// When empty the default TTFDPI is used (nothing is changed)
config.renderDPI=300

The reason would be because properly you want to have the whole page  
rendered at a different resolution anyways.


About color management,
yes the lack of different color models (CMYK, Panthone etc)
is a problem really for proper prepress work.

>
>> I have also worked on DB driven catalogs myself but we decided not
>> to let anything be rendered by TYPO3 but we used LaTeX and
>> a custom extension that utilizes PDFLib for Index creation, page  
>> number
>> for odd/even pages etc.
>
> I my case I meant a bit different thing. Not TYPO3 is creating the
> catalog as PDF, but the DTP software based on XML schemes provided by
> TYPO3. That way you can either automize things in your DTP software
> (like Adobe InDesign) or use dynamic content from the XML sheets  
> inside
> your DTP software.

Our requirement was using Open Source technologies (in the spirit of  
TYPO3)
but also on demand, I don't believe that on-demands is possible using
Adone InDesign.
With on-demand I mean we could generate a flyer in less then 5 seconds
and a 120page full-color catalog (CMYK) could be done in around 30  
seconds.
LaTeX is amazing fast!!!

>
>> The mayor problem with TYPO3 as your render engine is that TYPO3 (and
>> the web)
>> doesn't support the CMYK color model and you cannot define your
>> page very well so using TYPO3 as your typesetter is just bogus and
>> will never work really well (but can work if allow for concessions).
>
> Imagemagick allows for different color-profiles and color-conversion -
> although it might not produce the best results. Nowadays you don't
> necessarily need CMYK anmore, as long as your RGB file has a profile
> attached and the PDF document defines a profile.

I don't agree, although you can get good results with RGB models  
nowdays,
CMYK beats RGB hands down for printing work.

Ries





			regards, Ries van Twisk


-------------------------------------------------------------------------------------------------
Ries van Twisk
tags: Freelance TYPO3 Glassfish JasperReports JasperETL Flex Blaze-DS  
WebORB PostgreSQL DB-Architect
email: ries at vantwisk.nl
web:   http://www.rvantwisk.nl/
skype: callto://r.vantwisk
Phone: +1-810-476-4196
SIP: +1-747-690-5133