[Bf-docboard] less graphics

Thu, 02 Jan 2003 09:30:55 -0600

--------------070908070303010009070100
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Thanks! I need to download that and see what's there. :)

Stefano Selleri wrote:

>This is a very nice and much more complete
>proposal that the one in the Style guide :)
>
>>>1. A set of graphics standards would be set up. This would include
>>>conventions for size and content, i.e.: 300x200 pixel JPG at 50%
>>>compression for the Web-based and other online documentation; 300x200
>>>pixel JPG at 90% compression for a high-res PDF; and  2"x1.5" 300dpi
>>>CMYK EPS for the print version. The image would contain only the 3D pane
>>>for examples, or the button pane for settings.
>>>
>
>For 3D pane and Buttons I'd rather push for PNG, not JPG, after all they
>are usually low color number images, which would benefit
>from a lossless compression.
>
>Of course renderings is another matter, but you won't make 300x200 pixel
>renderings, do you?
>
That's a good point, I just used jpg's as an example. There should be a 
standard for both jpg's and png's.

As far as renderings, we'd want a few different sizes, but they would 
probably be rendered at print size and then scaled down to 300x200 or 
whatever size is determined looks best on the screen.

>>>2. Any screenshots would be done as large as possible, and any
>>>renderings would be done to take into account finished output size, for
>>>example, 1200x1200 for an image that would go on the printed page at a
>>>finished size of 4"x4"
>>>
>
>Yes, but this will make Doc CVS veeery big ;) .
>
True. We'd have to make a decision as to whether we'd want to offer the 
printable version for download in the CVS tree. I'd imagine we could 
offer the online versions in the tree, but not the printable version, if 
for no other reason than I could see people CVSing several dozen 10MB 
EPSes! :)

>>>3. Someone (an individual or team of individuals) would collect the
>>>images, process them according to the standards, and output them in two
>>>or three versions with identical content, one for Web, one for print,
>>>and one for a high-res PDF. These images would then be returned to the
>>>source tree for inclusion in their respective products.
>>>
>>Better yet, why not ask authors to include .blend files instead of
>>graphics? We could automate the rendering of the graphics during the
>>make process of the documentation and generate the graphics up to any
>>resolution that we like! It may take a bit of figuring out how to
>>indicate cutouts and such, but I think it is doable.
>>
>
>I think this is a great idea if you then make the .blend file
>available as a link within the documentation, so that
>reader can experiment, it is also usefull since it allows you
>to re-create all images at a different size/resolution if the need arises,
>but I would still ask the authors for images.
>
I agree. They could be offered on a companion CD with the book, and as 
an attachment to a PDF. For the common UI screenshots, the author could 
just specify what they want, but I agree if someone's modeling something 
they created as an example, it would be good to have even a low-quality 
screencap just "FPO" (for placement only).

Alex

--------------070908070303010009070100
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html>
<head>
</head>
<body>
Thanks! I need to download that and see what's there. :)<br>
<br>
Stefano Selleri wrote:<br>
<blockquote type="cite" cite="mid:00af01c2b23b$69db4eb0$080ea8c0@agave">
  <pre wrap="">This is a very nice and much more complete<br>proposal that the one in the Style guide :)<br><br></pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">1. A set of graphics standards would be set up. This would include<br>conventions for size and content, i.e.: 300x200 pixel JPG at 50%<br>compression for the Web-based and other online documentation; 300x200<br>pixel JPG at 90% compression for a high-res PDF; and  2"x1.5" 300dpi<br>CMYK EPS for the print version. The image would contain only the 3D pane<br>for examples, or the button pane for settings.<br></pre>
      </blockquote>
      </blockquote>
      <pre wrap=""><!----><br>For 3D pane and Buttons I'd rather push for PNG, not JPG, after all they<br>are usually low color number images, which would benefit<br>from a lossless compression.<br><br>Of course renderings is another matter, but you won't make 300x200 pixel<br>renderings, do you?</pre>
      </blockquote>
That's a good point, I just used jpg's as an example. There should be a standard
for both jpg's and png's.<br>
      <br>
As far as renderings, we'd want a few different sizes, but they would probably
be rendered at print size and then scaled down to 300x200 or whatever size
is determined looks best on the screen.<br>
      <br>
      <blockquote type="cite" cite="mid:00af01c2b23b$69db4eb0$080ea8c0@agave">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">2. Any screenshots would be done as large as possible, and any<br>renderings would be done to take into account finished output size, for<br>example, 1200x1200 for an image that would go on the printed page at a<br>finished size of 4"x4"<br></pre>
            </blockquote>
            </blockquote>
            <pre wrap=""><!----><br>Yes, but this will make Doc CVS veeery big ;) .</pre>
            </blockquote>
True. We'd have to make a decision as to whether we'd want to offer the printable
version for download in the CVS tree. I'd imagine we could offer the online
versions in the tree, but not the printable version, if for no other reason
than I could see people CVSing several dozen 10MB EPSes! :)<br>
            <br>
            <blockquote type="cite" cite="mid:00af01c2b23b$69db4eb0$080ea8c0@agave">
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre wrap="">3. Someone (an individual or team of individuals) would collect the<br>images, process them according to the standards, and output them in two<br>or three versions with identical content, one for Web, one for print,<br>and one for a high-res PDF. These images would then be returned to the<br>source tree for inclusion in their respective products.<br></pre>
                  </blockquote>
                  <pre wrap="">Better yet, why not ask authors to include .blend files instead of<br>graphics? We could automate the rendering of the graphics during the<br>make process of the documentation and generate the graphics up to any<br>resolution that we like! It may take a bit of figuring out how to<br>indicate cutouts and such, but I think it is doable.<br></pre>
                  </blockquote>
                  <pre wrap=""><!----><br>I think this is a great idea if you then make the .blend file<br>available as a link within the documentation, so that<br>reader can experiment, it is also usefull since it allows you<br>to re-create all images at a different size/resolution if the need arises,<br>but I would still ask the authors for images.<br></pre>
                  </blockquote>
                  <blockquote type="cite" cite="mid:00af01c2b23b$69db4eb0$080ea8c0@agave"></blockquote>
I agree. They could be offered on a companion CD with the book, and as an
attachment to a PDF. For the common UI screenshots, the author could just
specify what they want, but I agree if someone's modeling something they
created as an example, it would be good to have even a low-quality screencap
just "FPO" (for placement only).<br>
                    <br>
Alex<br>
                    </body>
                    </html>

--------------070908070303010009070100--