octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Color output for documentation eps images


From: Ben Abbott
Subject: Re: Color output for documentation eps images
Date: Thu, 03 Dec 2009 19:50:14 -0500

On Dec 3, 2009, at 6:41 PM, Robert T. Short wrote:

> Rik wrote:
>>   
>>>> Maybe we don't need to follow them slavishly?  The documentation from
>>>> Matlab is here:
>>>> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/print.html.
>>>> There is a printopts.m file which is configurable to set the default
>>>> print engine so at least there is a way to get around specifying
>>>> '-color' for every single saved plot.
>>>> 
>>>> Also, for consistency we should probably generate black and white
>>>> postscripts when printing.  I just did a test and printed an image with
>>>> no arguments.  My printer wasn't plugged in so I could take a look at
>>>> the generated file in the printer spool.  It is a color file apparently
>>>> generated with '-dpsc2'
>>>> 
>>>> --Rik
>>>> 
>>> I'd forgotten about Matlab's printopt.
>>> 
>>> Shall we add this to Octave?
>>>     
>> I'd say yes.  But, I'd also vote for changing the default printer driver
>> to '-dpsc2' immediately.  As you wrote in an earlier e-mail, nothing bad
>> is going to happen if a color file gets generated.  It will be passed
>> seamlessly by color devices and squashed to monochrome by those who
>> can't handle color.  I've been bitten by printing a figure to a file
>> only to have to redo it because it came out in black and white.
>> 
>> --Rik
> 
> Not true.  A color file will get squashed to gray scale by most publishers 
> and many colors render very poorly when printed that way.  I have been bitten 
> by printing and having it come out color.  If you print black and white and 
> display it on a color device, you won't be wrong but if you print color and 
> print on a black and white device (e.g. laser printer), you may not catch the 
> error until the book comes out.  Of course, these are all specious arguments 
> since I can't imagine publishing without checking such things.
> 
> 
> This is really a tempest in a teapot folks.  No matter what you pick it will 
> be right for some, wrong for others.
> 
> Do it the way MATLAB does it or don't change anything at all.  Of course the 
> person writing the code probably gets to do it his/her way!
> 
> Bob

Although there are times my head spins trying to figure out what Mathworks was 
thinking when they implemented a particular default behavior, I'm in favor of 
maintaining compatibility, and extending functionality to permit ease of use.

Before I integrated the result with print.m, I'd like some feedback on the 
attached printopt.m.

The printopt.m attached would be used by print.m to determine the shell command 
used to spool output to a printer, as well as to determine the default output 
format. As the printopt.m is a function that allows its defaults to be 
modified, specifying the proper output format for the documentation is a simple 
task.

Any concerns?

Ben

Attachment: printopt.m
Description: Binary data




reply via email to

[Prev in Thread] Current Thread [Next in Thread]