[Bf-docboard] less graphics

[Alex Heizer]

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

Hey Bart,


Bart Veldhuizen wrote:

>Hi Alex,
>
>On Tue, 2002-12-31 at 20:06, Alex Heizer wrote:
>
>I think this is a great proposal! It has only partially been described
>in the Style Guide (see the link I sent earlier), so any additions that
>you can make to it and to the general documentation process would be
>greatly appreciated. I have included some comments below.
>
>>Matt Ebb and I volunteer to work on this, if that's what everyone wants. 
>>I just know from working with both print and Web that you need to take 
>>different things into account for each as far as graphics are concerned. 
>>What I propose, would be something along the lines of this:
>>
>>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.
>>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".
>>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.
>
That would be a great idea. If authors cared about the particular 
layout, they could make a lo-res screencap or render to show what they 
wanted and send it with the .blend file.  That could be one of the 
things specified in the standards.


>>4. Someone (an individual or team of individuals) would come up with a 
>>cool, professional design that would showcase blender as a great program 
>>that talented people do and should use and be a part of. Since print 
>>design is different than Web design, that someone could create a couple 
>>of slightly different, but complementary designs that make blender look 
>>cool and professional whichever version you're looking at.
>>5. The someone's in points 3 and 4 would coordinate the design and 
>>content to make sure it all looks consistent. This could also free up 
>>authors to not worry about style and focus on content, since the 
>>designers could ensure everything's formatted correctly and maintain one 
>>copy.
>>
>>From what I understand, we can do a nice design once for the docbook, 
>>which can then be output in different formats, like for a Website or a 
>>plaintext version or for print. In which case, we should be able to set 
>>up output templates so that when the online version is output it uses 
>>the lo-res bitmaps, and when the printed version is output it will use 
>>the high-res EPSes.
>>
>
>That is correct. We need to create stylesheets for each transformation
>of DocBook/XML --> PDF, HTML or whatever. I'm not sure how difficult
>this would be for the PDF version though, but we may be able to find
>someone who likes to dig into this.
>

I'll work with Matt (I'll see if he's still interested in working on 
this) on making a design for the pages (overall layout, etc.)
and make some graphics standards suggestions. We'll make up designs for 
a printed book as well as a Web site, which will mirror the printed 
design, but be more Web-friendly. If someone who knows more about 
working with DocBook/XML wants to help out, that would be cool too.

Alex 


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

<html>
<head>
</head>
<body>
Hey Bart,<br>
<br>
<br>
Bart Veldhuizen wrote:<br>
<blockquote type="cite" cite="mid:1041492444.1014.29.camel@ferro">
  <pre wrap="">Hi Alex,<br><br>On Tue, 2002-12-31 at 20:06, Alex Heizer wrote:<br><br>I think this is a great proposal! It has only partially been described<br>in the Style Guide (see the link I sent earlier), so any additions that<br>you can make to it and to the general documentation process would be<br>greatly appreciated. I have included some comments below.<br><br></pre>
  <blockquote type="cite">
    <pre wrap="">Matt Ebb and I volunteer to work on this, if that's what everyone wants. <br>I just know from working with both print and Web that you need to take <br>different things into account for each as far as graphics are concerned. <br>What I propose, would be something along the lines of this:<br><br>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>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>3. Someone (an ind
ividual 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=""><!----><br>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>
That would be a great idea. If authors cared about the particular layout,
they could make a lo-res screencap or render to show what they wanted and
send it with the .blend file. &nbsp;That could be one of the things specified
in the standards.<br>
    <br>
    <br>
    <blockquote type="cite" cite="mid:1041492444.1014.29.camel@ferro">
      <blockquote type="cite">
        <pre wrap="">4. Someone (an individual or team of individuals) would come up with a <br>cool, professional design that would showcase blender as a great program <br>that talented people do and should use and be a part of. Since print <br>design is different than Web design, that someone could create a couple <br>of slightly different, but complementary designs that make blender look <br>cool and professional whichever version you're looking at.<br>5. The someone's in points 3 and 4 would coordinate the design and <br>content to make sure it all looks consistent. This could also free up <br>authors to not worry about style and focus on content, since the <br>designers could ensure everything's formatted correctly and maintain one <br>copy.<br><br>From what I understand, we can do a nice design once for the docbook, <br>which can then be output in different formats, like for a Website or a <br>plaintext version or for print. In which case, we should be able to set <br>u
p output templates so that when the online version is output it uses <br>the lo-res bitmaps, and when the printed version is output it will use <br>the high-res EPSes.<br></pre>
        </blockquote>
        <pre wrap=""><!----><br>That is correct. We need to create stylesheets for each transformation<br>of DocBook/XML --&gt; PDF, HTML or whatever. I'm not sure how difficult<br>this would be for the PDF version though, but we may be able to find<br>someone who likes to dig into this.</pre>
        </blockquote>
        <br>
I'll work with Matt (I'll see if he's still interested in working on this)
on making a design for the pages (overall layout, etc.)<br>
and make some graphics standards suggestions. We'll make up designs for a
printed book as well as a Web site, which will mirror the printed design,
but be more Web-friendly. If someone who knows more about working with DocBook/XML
wants to help out, that would be cool too.<br>
        <br>
Alex&nbsp;
        <blockquote type="cite" cite="mid:1041492444.1014.29.camel@ferro"></blockquote>
          </body>
          </html>

--------------020108050301030806010708--