TERM=sun-color

I have recently discovered a new feature of Solaris 10 which is to have colours within my shell by TERM=sun-color. I use bash.
The problem is that the screen is not cleared, so for example if i type in ls, and then vi a file, the output from the ls is still visible.
There must be some way to fix this, or to configure my terminal correctly to make the maximum use of it.

Wolfgang073 wrote:
Hi guys and ladys!
I added the LD_LIBRARY_PATH, Why are you doing that. It's probably a bad idea.
but the Openwindows not run OK (e.g. start cmdtool window without csh % prompt etc.).That's very possible. Don't make global changes to LD_LIBRARY_PATH (by putting in your login files for example). Instead if you need it to run a particular program, make a wrapper that sets the variable and then calls the program. That will limit the scope of those changes.
vi .login
# Erasing LD_LIBRARY_PATH
setenv LD_LIBRARY_PATH
# Important Paths set
setenv LD_LIBRARY_PATH /usr/ucblib:$LD_LIBRARY_PATHDon't do that.
Darren

Similar Messages

[Solved] 256 color term causes color glitch

Hello,
I'm having a strange (to me anyways) issue with 256 color terminals. The issue appears under xterm-256color and rvxt(-unicode)-256color, but not under any of the 8-color terminals I've tried.
A bit of background, if it's relevant: this is my second machine running Arch. It's an Asus netbook which I intend to use for schoolwork-related stuff (therefore, no need for X or a DE -- just console tools). I'm trying to get a 256 color term working because I use emacs, and mc a lot, and they both have nice 256 color themes I'd like to use.
However, when I use a 256 color term, the following happens:
The universal issue is that the colors are wrong -- lots of them are the same blue and grey color repeated again and again. This is I think what is causing emacs/mc and others to do all of their colored highlighting in an unreadable mess of these same colors everywhere. The issue particular to rxvt-unicode-256color (and not rxvt-256color) is the other effect shown in the picture -- the text becomes 'distorted' into incorrect characters. The text typed in on the left, for example, are two ordinary sentences.
Maybe what I'm looking at in the unicode term is two unrelated issues... I'm not sure. In any case, if someone could point me in the direction of a solution or offer some insight, I'd appreciate it.
Thanks!
Last edited by jasonwryan (2013-02-26 17:22:36)

jasonwryan wrote:This is likely an issue with your terminfo. You aren't setting a TERM value in your shell .rc file are you?
You've caught me redhanded, but more importantly you've finally given me a new name to look into. After several rounds of tic-terminfo-toe, I'm satisfied that as trilby says there simply is no way to get the full 256 color range out of the tty without some x in the middle. This leads to more questions (where's the equivalent of inittab for systemd, where does term get set to xterm anyway (when not in the user's rc's at least, why did it work better through pts, can I achieve 256 in pts without forwarding x, where do I find an 8-color vim syntax scheme that won't burn my eyeballs, etc), but the topic question is resolved. Thanks!

How to set up new enviroment variables permanently for all users?

Hi.
I downloadad Apache Tomcat, and need to set enviromental variables for all users.
I tryed setenv commad, but it is not found.
for example # JAVA_HOME="/opt/jre1.6.0" Solaris remembers this variable only for one session and I need for all users permanently.
Thanks.

Thank you.
This file contains a script. Is there difference in putting that line in beginning or end of the file?
#ident     "@(#)profile     1.19     01/03/13 SMI"     /* SVr4.0 1.3     */
# The profile that all logins get before using their own .profile.
trap "" 2 3
export LOGNAME PATH
if [ "$TERM" = "" ]
then
     if /bin/i386
     then
          TERM=sun-color
     else
          TERM=sun
     fi
     export TERM
fi
#     Login and -su shells get /etc/profile services.
#     -rsh is given its environment in its .profile.
case "$0" in
-sh | -ksh | -jsh | -bash)
     if [ ! -f .hushlogin ]
     then
          /usr/sbin/quota
          #     Allow the user to break the Message-Of-The-Day only.
          trap "trap '' 2" 2
          /bin/cat -s /etc/motd
          trap "" 2
          /bin/mail -E
          case $? in
          0)
               echo "You have new mail."
          2)
               echo "You have mail."
          esac
     fi
esac
umask 022
trap 2 3
# Intel Server Control - The following lines
# let the LRA daemon access the X server
if [ -f /usr/bin/X11/xhost -a -f //isc/lra ]
then
     ttyname=`tty`
     ttyname=`basename $ttyname`
     ttykind=`tty | egrep "console|vt"`
     whereami=`finger -s | grep $ttyname | cut -c61-`
     if [ "$whereami" = "" -a "$ttykind" = "" ]
     then
          CURDIS=$DISPLAY
          DISPLAY=unix:0.0
          export DISPLAY
          /usr/X/bin/xhost +unknown 2>/dev/null 1>/dev/null
          DISPLAY=$CURDIS
     fi
fi

Help needed, example (serial port) streams module not working.

I am trying to make work the tblt.c example of a streams module on Solaris 8.
This sample is the one provided by Sun in it's Driver Dev. Kit.
My test program gets blocked in the I_PUSH ioctl (after having successfully
poped ttcompat and ldterm).
Debug prints in the module tell me that the tbltopen() stays in the loop
     * Now wait for it. Let our read queue put routine wake us up
     * when it arrives.
     while (tbltd->tbltd_flags & TBLT_IOCWAIT) {
          if (!qwait_sig(q)) {
               lwp_error = EINTR;
               goto error;
done, after
iocb = (struct iocblk *)mp->b_wptr;
     iocb->ioc_count = sizeof (struct iocblk);
     cb = (struct termios *)datap->b_wptr;
     cb->c_iflag = 0;
     cb->c_oflag = 0;
     cb->c_cflag = CREAD|CS8|B9600;
     cb->c_lflag = 0;
     bzero((caddr_t)cb->c_cc, NCCS);
     datap->b_wptr += sizeof (*cb)/(sizeof (*datap->b_wptr));
     mp->b_cont = datap;
     tbltd->tbltd_flags |= TBLT_IOCWAIT;     /* indicate that we're */
     tbltd->tbltd_iocid = iocb->ioc_id;     /* waiting for this response */
     (void) putnext(WR(q), mp);
(used to set baudrate, I suppose)
and only a Ctlr-C of my test prog. makes it return via
lwp_error = EINTR;
               goto error;
A few years ago, I had no trouble with the same Solaris 5 example.
and my hardware (tablet + cable) works fine on a Solaris 5 system.

darren,
thanks for your help here and over on comp.sys.solaris. ultimately the problem was portmon on ttya, and i think i know how it happened. the machine was set up with a keyboard and monitor, and ttya was enabled using admintool. later, with the machine headless, the console was changed over to ttya via eeprom, which produced the conflict i noted above.
solution:
# pmadm -l
PMTAG PMTYPE SVCTAG FLGS ID <PMSPECIFIC>
zsmon ttymon ttyb u root /dev/term/b I - /usr/
bin/login - 9600 ldterm,ttcompat ttyb login: - tvi925 y #
zsmon ttymon ttya u root /dev/term/a - - /usr/
bin/login - 9600 ldterm,ttcompat neo ttya login: - vt100 y #Terminal
# pmadm -d -p zsmon -s ttya
# pmadm -l
PMTAG PMTYPE SVCTAG FLGS ID <PMSPECIFIC>
zsmon ttymon ttyb u root /dev/term/b I - /usr/
bin/login - 9600 ldterm,ttcompat ttyb login: - tvi925 y #
zsmon ttymon ttya ux root /dev/term/a - - /usr/
bin/login - 9600 ldterm,ttcompat neo ttya login: - vt100 y #Terminal
# echo $TERM
sun-color
# svccfg
svc:> select system/console-login
svc:/system/console-login> setprop ttymon/terminal_type = "vt100"
svc:/system/console-login> exit
# echo $TERM
vt100
also see
http://www.bordergatewayprotocol.net/jon/helpful_stuff/solaris/solaris-advanced-sysadmin-guide/ch09/181-186.html

Terminal type problem

Hi,
I've recently installed solaris 10 x86 under VM ware and everything has went smoothly.
I have a problem however when I upon up a terminal window and try and use the pipe "|" symbol as I can't seem to use it...When I try and enter this character I get "~" instead of "|"...
I've tried using kdmconfig but can't seem to get anything that works. I've tried both the UK and UK english versions of the keyboard with no luck and I've also tried setting TERM=vt100 to no ovail.
The only time I've had this work is when I managed to boot up straight to a command prompt which gave me a TERM of sun-color if I recall. I tried setting TERM=sun-color via a terminal window but this didn't work so it's very confusing. I have a sony VAIO laptop and running solaris within VMWARE...
Any help much appreciated but without the "|" I can't do that much in the way of core unix commands e.g. ps -eaf | more, cat <file> | more etc
Hopefully there is a simple answer. I've search the forums by the way and could find a similar problem but that was for a few versions backl where the solution was to upgrade.

Try using ANSI, it seems to work better for some terminals, especially over ssh. xterm is the second best option. VT100 is a legacy termtype, it doesn't work very well with terminal emulators.

Color calibration issues - blue tint w/ sRGB

Need some help getting this issue resolved & wondering if there is a problem with my LCD.
I do a lot of web and video work and recently moved from a 17" Powerbook G4 to a 17" MacBook Pro. Both used with a 20" Apple Cinema display. The color temperature (tint) between the Powerbook and the new MacBook Pro are drastically different - especially when using sRGB calibration which is recommended by Adobe for this type of work. The cinema display seems correct and closely matches my Powerbook when using sRGB, but the Macbook Pro is very blue. The Macbook Pro displays more warm grays vs. the cinema display when using the default calibration settings.
Using sRGB for both displays:
http://idisk.mac.com/edgedesign-Public/Calibration/photo_sRBG.jpg
Using default calibration for both displays:
http://idisk.mac.com/edgedesign-Public/Calibration/photo_default.jpg
*Notice the 20" cinema hardly changes in either of these shots which make me think there's a problem with the MacBook Pro display.
- Are all the new MacBook Pros like this?
- Why so different than the Powerbook display and Cinema displays?
- Any calibration suggestions for Adobe CS3 and screen work?

Brief intro before I pontificate: I have a degree in imaging and used to be one of the guys you talked to at Eastman Kodak about monitor color calibration (before Kodak drove me crazy).
A few points:
First, sRGB is a needlessly small gamut color space invented by Microsoft. In the professional imaging field it is looked at with great disdain because it is imposing a needless crushing of your monitor's color profile. I've talked to one of the color experts at Adobe and he completely agrees. I don't know who at Adobe is recommending sRGB, but they are W R O N G. I personally call sRGB 'StupidRGB' in order to remind myself exactly what it is worth.
Second, the field of color calibration, color matching and color correction is complicated and requires considerable understanding to perform correctly. There are entire books on the subject, well worth reading. You can even take classes on the subject, such as at Rochester Institute of Technology (plugging my Alma matter). If you have shopped around for color calibration devices you will find they are incredibly expensive, and there is a reason for that.
Third, LCD screens generally SUCK for color matching. Here are a few reasons why:
(A) The viewing angle of most LCD screens is so small that if you tilt your head up, down, right or left you end up with a shift in color balance and contrast. Result: no way can you accurately color match. This is most certainly the case with ALL MacBooks, MacBook Pros and iMacs. The Cinema displays are vastly better. You can check this out yourself at your local Apple Store.
(B) In case you had not heard, none of the MacBook or MacBook Pro laptops are capable of showing all colors to which the human eye is sensitive. They don't do 'millions of colors' despite advertising you have read. They do about 260,000 colors and dither the rest. Dithering does NOT create colors that are not there. It just fakes them. The result again is that it is impossible to use these LCDs for accurate color matching. I have no knowledge about whether this color problem is the case with iMacs, but refer to the paragraph above regarding their viewing angle problem.
(C) The color gamut on even the very best LCD display is at the mercy of the fluorescent light bulbs inside the displays. The massive problem with fluorescent lights is that they do not have a continuous color spectrum. What you get are specific wavelength peaks with complete dropouts of other colors. Ye old CRTs with electron guns and glowing phosphors were/are not perfect either, but they were/are MUCH better at representing the full spectrum of light. Their gamut is much larger and more accurate than any LCD display. CRTs remain THE professional display for color calibration and color matching, even today.
I could rant on, but I think you get the message: Color matching on LCDs is a lousy idea, and on MacBooks and MacBook Pros it is essentially an impossible idea. The colors you need are not there on the screen. What you see is not what you get in terms of color. Give up.
That having been said, you can optimize your results for guestimation purposes. The very first thing I do with ANY display, including on Mac laptops, is go into the 'Displays' preference pane, hit the 'Color' tab and 'Calibrate...' the display. You MUST use 'Expert Mode'. Don't bother with mickey mouse mode. Fiddling with the settings will drive you nuts at first. But practice makes perfect. As long as you are not color blind you WILL get the hang of it, even if you don't understand what it is doing. Don't get psyched out. It works rather well.
When you get to 'Gamma' (you can look these terms up on Wikipedia) you want to use the same Gamma number as the other monitor you will be using for viewing. 1.8 is fine for Macs. Beats me why the 'PC' standard is 2.2. It is essentially a harsher contrast, but try it and use it if you like it, on BOTH monitors. Do NOT use 'native gamma' as it is rare that two displays have identical native gammas.
Next up is your 'white point'. Again, you want both your displays to have the same white point. D50 is the standard for viewing images in daylight. D65 is a bluer 'white point'. 9300 is the bluest of all. These numbers represent 'color temperature' as it is called. The sun has a color temperature hovering around 5000º Kelvin, thus D50 where D = Display. D65 = 6500º Kelvin, etc. Again, there is lots to read about in this field. Do NOT use 'native white point' on your displays if you are color matching because again, they won't be the same on each display.
When you get to the point of naming your color calibration profile you MUST include in the name the gamma number you used and the white point number you used. You will want to know, believe me. Here is why: You are going to want to make further color calibration profiles for different situations either now or in the future. Here's one example:
Lighting environment: Are you working on your MacBook Pro in the dark? Are the walls in the room a neutral color? Or are the walls colored? What kind of light is being used in the room? Fluorescent? Incandescent? Daylight? Details in the lighting environment in which you are working will affect how you perceive color on your display! You may want a morning color profile, an afternoon sun profile, and a night profile. If you have windows near you, these different times of day will affect the light in your work area and how you perceive color on your display. Again, go find a good book if you really want to understand this stuff.
A good basic calibration for plain old every day work, useless for color matching but nice to look at: I go through the calibration process for my lighting environment then use a gamma of 1.8 and I check off 'Use native white point'. Why? LCDs look their best at their native white point. You get good contrast with optimum color. Try it, you'll like it.
:-Derek

(Not so) Juicy colors

Comparing to my Cinema Display plugged to G5, colors on MacBook Pro are not that vivid as I would like them to be. I know that there is no way to create identical color profiles on both machines but is there any sufficent method to adjust my colors on MacBook Pro? I tried to make an optimal LCD profile but I'm not satisfied. Should I try other applications? Cheers!

I thought the color gamut situation with MacBooks and MacBook Pros was common knowledge by now.
The Apple Cinema Display can show all the colors to which the human eye is sensitive. This is called 24 bit color (8 bits each for red, green and blue) or 'millions of colors'.
However, this is NOT the case with any of Apple's laptops. Despite what you have read, they are incapable of showing millions of colors. Instead they use 6 bits per color or 18 bit color. This is approximately 260,000 colors. The operating system then uses dithering to fake the missing colors. The results is, as you have noticed, no way as good as true 24 bit color on a Cinema Display.
Doing color calibration and color matching with LCD displays in general *****, but considering the above limitation of all Mac laptops it is essentially impossible. The best you are going to get is a guestimation.
I wrote a brief dissertation about color calibration for another inquiry. Forgive me folks for posting this thing over and over and over again, but apparently this is a subject that plagues a lot of people. The original inquiry involved using the sRGB color space, so skip over that section if you like. Hopefully my notes will give you some assistance:
Brief intro before I pontificate: I have a degree in imaging and used to be one of the guys you
talked to at Eastman Kodak about monitor color calibration (before Kodak drove me crazy).
A few points:
First, sRGB is a needlessly small gamut color space invented by Microsoft. In the professional
imaging field it is looked at with great disdain because it is imposing a needless crushing of your
monitor's color profile. I've talked to one of the color experts at Adobe and he completely agrees. I
don't know who at Adobe is recommending sRGB, but they are W R O N G. I personally call sRGB
'StupidRGB' in order to remind myself exactly what it is worth.
Second, the field of color calibration, color matching and color correction is complicated and
requires considerable understanding to perform correctly. There are entire books on the subject,
well worth reading. You can even take classes on the subject, such as at Rochester Institute of
Technology (plugging my Alma matter). If you have shopped around for color calibration devices
you will find they are incredibly expensive, and there is a reason for that.
Third, LCD screens generally SUCK for color matching. Here are a few reasons why:
(A) The viewing angle of most LCD screens is so small that if you tilt your head up, down, right or
left you end up with a shift in color balance and contrast. Result: no way can you accurately color
match. This is most certainly the case with ALL MacBooks, MacBook Pros and iMacs. The Cinema
displays are vastly better. You can check this out yourself at your local Apple Store.
(B) In case you had not heard, none of the MacBook or MacBook Pro laptops are capable of showing
all colors to which the human eye is sensitive. They don't do 'millions of colors' despite advertising
you have read. They do about 260,000 colors and dither the rest. Dithering does NOT create colors
that are not there. It just fakes them. The result again is that it is impossible to use these LCDs for
accurate color matching. I have no knowledge about whether this color problem is the case with
iMacs, but refer to the paragraph above regarding their viewing angle problem.
(C) The color gamut on even the very best LCD display is at the mercy of the fluorescent light
bulbs inside the displays. The massive problem with fluorescent lights is that they do not have a
continuous color spectrum. What you get are specific wavelength peaks with complete dropouts of
other colors. Ye old CRTs with electron guns and glowing phosphors were/are not perfect either,
but they were/are MUCH better at representing the full spectrum of light. Their gamut is much larger and more accurate than any LCD display. CRTs remain THE professional display for color calibration and color matching, even today.
I could rant on, but I think you get the message: Color matching on LCDs is a lousy idea, and on
MacBooks and MacBook Pros it is essentially an impossible idea. The colors you need are not there
on the screen. What you see is not what you get in terms of color. Give up.
That having been said, you can optimize your results for guestimation purposes. The very first
thing I do with ANY display, including on Mac laptops, is go into the 'Displays' preference pane, hit
the 'Color' tab and 'Calibrate...' the display. You MUST use 'Expert Mode'. Don't bother with mickey
mouse mode. Fiddling with the settings will drive you nuts at first. But practice makes perfect. As
long as you are not color blind you WILL get the hang of it, even if you don't understand what it is
doing. Don't get psyched out. It works rather well.
When you get to 'Gamma' (you can look these terms up on Wikipedia) you want to use the same
Gamma number as the other monitor you will be using for viewing. 1.8 is fine for Macs. Beats me
why the 'PC' standard is 2.2. It is essentially a harsher contrast, but try it and use it if you like it, on
BOTH monitors. Do NOT use 'native gamma' as it is rare that two displays have identical native
gammas.
Next up is your 'white point'. Again, you want both your displays to have the same white point. D50
is the standard for viewing images in daylight. D65 is a bluer 'white point'. 9300 is the bluest of all.
These numbers represent 'color temperature' as it is called. The sun has a color temperature
hovering around 5000o Kelvin, thus D50 where D = Display. D65 = 6500o Kelvin, etc. Again, there
is lots to read about in this field. Do NOT use 'native white point' on your displays if you are color
matching because again, they won't be the same on each display.
When you get to the point of naming your color calibration profile you MUST include in the name
the gamma number you used and the white point number you used. You will want to know, believe
me. Here is why: You are going to want to make further color calibration profiles for different
situations either now or in the future. Here's one example:
Lighting environment: Are you working on your MacBook Pro in the dark? Are the walls in the room
a neutral color? Or are the walls colored? What kind of light is being used in the room?
Fluorescent? Incandescent? Daylight? Details in the lighting environment in which you are working
will affect how you perceive color on your display! You may want a morning color profile, an
afternoon sun profile, and a night profile. If you have windows near you, these different times of
day will affect the light in your work area and how you perceive color on your display. Again, go
find a good book if you really want to understand this stuff.
A good basic calibration for plain old every day work, useless for color matching but nice to look
at: I go through the calibration process for my lighting environment then use a gamma of 1.8 and I
check off 'Use native white point'. Why? LCDs look their best at their native white point. You get
good contrast with optimum color. Try it, you'll like it.
:-Derek

Color management, printing with InDesign CS3

RGB output devices (this includes essentially all inkjet printers from every manufacturer, when driven by the manufacturer print driver). Inkjet printers driven by a PostScript RIP are considered CMYK output devices, and thus this post does not apply to them.
When printing to RGB output devices from InDesign using the same ICC profiles and settings as in Photoshop, you still get crummy results, in terms of color, that differ from both IDCS2 and other Adobe applications including Photoshop CS3.
InDesign CS2 previously did all rasterizing and color space conversion in InDesign prior to submitting the print job to the OS. In CS3 this was changed to submit PostScript + colorspace information, which is then supposed to be normalized by the OS. Except that it doesn't work. Mac OS X drops the color space information.
The work around is to check "Print as Bitmap" in the advanced section of the IDCS3 print dialog. This causes IDCS3 to do the conversion and generate a bitmap prior to submitting to the OS, rather than depending on the OS to do color conversion or rasterizing, which is the default behavior with IDCS2. Thus you can use the same ICC profiles and print driver settings as with all other Adobe applications, if you choose this option.
Chris Murphy
co-author Real World Color Management 2e

Chris,
First, I am surprised that there has been no response to your post since there were more than a few complaints about the problem in this forum when IDCS3 first came out. So thank you for the solution to this vexing problem.
But I find some of the language in your post a bit problematic:
>InDesign CS2 previously did all rasterizing and color space conversion in InDesign prior to submitting the print job to the OS.
and
>... rather than depending on the OS to do color conversion or rasterizing, which is the default behavior with IDCS2.
The second quote seems incorrect on two counts:
1. It contradicts the first quoted statement.
2. In my mac IDCS2 (version 4.0.5 build 688) in the options area of the color management pane of the print dialog, the only available choice for the Color Handling pop up is "Let InDesign Determine Colors".
So the default behavior with IDCS2 seems to be "Let InDesign Determine Colors".
I am not at all taking issue with the main point of your post, which I welcome wholeheartedly. I just find the second quoted phrase from you post confusing. Can you please clarify.
Returning to your main point, are there any downsides of using the Print as Bitmap method?
Thanks,
Al

Plot colors mismatched with legend

Does any happen to know why colors on a graph would not match the colors indicated in the legend?
I am trying to use a property node to set the color and name for each set of data which is displayed. The colors and names are displayed properly in the legend, but the color of the plot itself does not follow.
Attachments:
View_Collected_Data.vi ‏132 KB
data.txt ‏6 KB

The loop knows how many times to go due to a feature of LV called auto-indexing. If you pass in an array and let it autoindex on the boarder, the loop will automatically pull out the next value in the array with each iteration--AND set the number of time to loop before stopping. Compared to the hoops C makes you jump through to use arrays, this is indeed Very Cool...
Note that if you wire both the N terminal on a FOR loop, and autoindex an incoming array, the loop will iterate the smaller of the two sizes. For example, if you wire 5 to N and pass in an array with three elements, the loop will only go three times.
Finally, always remember that a FOR loop can iterate zero times. In that case any outputs coming directly from the loop will be
the default value for the datatype. Arrays will be empty, numbers will be zero'd and (this is a biggie) references numbers will be invalid(!).
In the case of your code, I modified the logic such that it generates an array of indexes that has one element for each signal selected. This array drives the loop that sets the plot properties. Note that if the operator selects more than 5 signals the higher-numbered plots will be undefined in terms of color and label because you only specify 5 colors in an array. (Input an array of 10 items and an array of 5 items and the loop only goes 5 times.)
Note that, although it's not used here, auto indexing also works with outputs. In that case though, the loop will automatically collect an array of the output values--one element per iteration.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Color Management in Acrobat 9: Still Not Sure What It's Doing... :o(

I'm still having some trouble getting my head around what Acrobat 9 is (not) doing in terms of color management. Hopefully someone can either confirm that I'm not crazy, or show me what I'm doing wrong (or what simple thing I'm missing):
Open a PDF that I know is tagged with an ICC profile.
Open Output Preview.
If Simulation Profile is set to the same profile then the CMYK values are correct.
If Simulation Profile is set to anything else the CMYK numbers are different. I would expect the appearance to be different, not the numbers. This makes no sense to me... it should be showing me how these CMYK values would output to different devices...
Also, I can't find a way to determine what the embedded profile is. (In this case I knew it was Web SWOP, since I intentionally created it that way, but what if I received a mystery PDF?) When I go to Document Properties it's listed as Tagged PDF: No, even though I know for certain that it does contain an embedded profile.
Output Preview always defaults to the last-use profile, even if the PDF contains an embedded profile. I would think that by default it would go to the embedded profile, and only use the last-used setting (or the default that is set up in preferences) if there was no embedded profile.
Seems like none of this jives with how color management works in every other Adobe app, or any other color-managed app for that matter. Am I just being dumb? (Be honest, I can take it!)

I'm still having some trouble getting my head around what Acrobat 9 is (not) doing in terms of color management. Hopefully someone can either confirm that I'm not crazy, or show me what I'm doing wrong (or what simple thing I'm missing):
Open a PDF that I know is tagged with an ICC profile.
Open Output Preview.
If Simulation Profile is set to the same profile then the CMYK values are correct.
If Simulation Profile is set to anything else the CMYK numbers are different. I would expect the appearance to be different, not the numbers. This makes no sense to me... it should be showing me how these CMYK values would output to different devices...
Also, I can't find a way to determine what the embedded profile is. (In this case I knew it was Web SWOP, since I intentionally created it that way, but what if I received a mystery PDF?) When I go to Document Properties it's listed as Tagged PDF: No, even though I know for certain that it does contain an embedded profile.
Output Preview always defaults to the last-use profile, even if the PDF contains an embedded profile. I would think that by default it would go to the embedded profile, and only use the last-used setting (or the default that is set up in preferences) if there was no embedded profile.
Seems like none of this jives with how color management works in every other Adobe app, or any other color-managed app for that matter. Am I just being dumb? (Be honest, I can take it!)

Color Managed Printing from LR 1.3.1 Inverse of Proper PS CS3 10.0.1 Behavior

Please excuse the length and detail of this post - I'm just trying to be very clear...
Also, it would be helpful if anyone having definitive information about this topic could please email me directly in addition to replying to this forum topic, in order that I might know a response is available sooner (I am new to this forum, and may not check it regularly). My direct email address is [email protected].
Bottom Line: Color managed printing using my own custom-generated profiles from LR 1.3.1 to my Epson 7600 (on Intel-based Mac OS X 10.5.2, but saw the same behavior with 10.5.1) using the current Epson 7600 Intel/10.5x-compatible driver (3.09) is broken, and appears to be doing the exact opposite (inverse) of what I would expect and what PS CS3 does properly.
I am color management experienced, and have been using my custom-generated EPSON 7600 profiles with reliable soft proofing and printing success in PS (both CS2 and now CS3) for some time now. I know how the EPSON printer driver should be set relative to PS/LR print settings to indicate desired function. Images exported from LR to PS and printed from PS using "Photoshop Manages Color" and proper printer driver settings ("No Color Adjustment") print perfectly, so it isn't the Intel-based Mac, the OS, the driver, the profile, or me -- it is LR behaving badly.
The specific behavior is that printing from LR using "Managed by Printer" with the EPSON driver's Color Management setting set properly to "Colorsync" prints a reasonable-looking print, about what you would expect for canned profiles from the manufacturer, and in fact identical to the results obtained printing the same image from PS using "Printer Manages Color". So far so good. Switching to my specific custom profiles in LR and printing with the driver's CM setting set properly to "No Color Adjustment" yields results that are clearly whacked, for both LR settings of "Perceptual" and "Relative CM". Just for completeness and out of curiosity, I tried printing from LR using the same profile (once for "Perceptual" and once more for "Relative CM") with the EPSON driver's CM setting set IMPROPERLY to "Colorsync", and the results were much more in line with what you would expect - I would almost say it was "correct" output. This is why I used the phrase "inverse of proper behavior" in the subject line of this topic. Going one step further, trying this same set of improper settings in PS (PS print settings set to "Photoshop Manages Color" with either Perceptual or Rel CM selected, but using "Colorsync" rather than "No Color Adjustment" in the Color Management pane of the EPSON printer driver) yields whacked results as you would expect that look identical to the whacked results obtained from LR using "proper" settings.
I said above that the improper settings from LR yielded results that I would almost say were correct. "Almost" because the benchmark results rendered by PS using proper settings are slightly different - both "better" and closer to each other - than those rendered by LR using the improper settings. The diffs between the Perceptual and Rel CM prints from LR using improper settings showed more marked differences in tone/contrast/saturation than the diffs observed between the Perceptual and Rel CM prints from PS using proper settings - the image itself was in-gamut enough that diffs between Perceptual and Rel CM in the proper PS prints were quite subtle. Even though the improper LR prints were slightly inferior to the proper PS prints, the improper LR prints were still within tolerances of what you might expect, and still better (in terms of color matching) than the "Managed by Printer" print from LR. At first guess, I would attribute this (the improper LR prints being inferior to the proper PS prints) to the CMM being used by LR being different from (inferior to) the CMM I have selected for use in PS (that being "Adobe (ACE)"). I can live with the LR CMM being slightly different from that use

(Here's the 2nd half of my post...)
I said above that the improper settings from LR yielded results that I would almost say were correct. "Almost" because the benchmark results rendered by PS using proper settings are slightly different - both "better" and closer to each other - than those rendered by LR using the improper settings. The diffs between the Perceptual and Rel CM prints from LR using improper settings showed more marked differences in tone/contrast/saturation than the diffs observed between the Perceptual and Rel CM prints from PS using proper settings - the image itself was in-gamut enough that diffs between Perceptual and Rel CM in the proper PS prints were quite subtle. Even though the improper LR prints were slightly inferior to the proper PS prints, the improper LR prints were still within tolerances of what you might expect, and still better (in terms of color matching) than the "Managed by Printer" print from LR. At first guess, I would attribute this (the improper LR prints being inferior to the proper PS prints) to the CMM being used by LR being different from (inferior to) the CMM I have selected for use in PS (that being "Adobe (ACE)"). I can live with the LR CMM being slightly different from that used in PS - that is not the issue here. What is at issue is trying to determine why LR is clearly behaving differently than PS in this well-understood area of functionality, all other variables being the same. (And, incidentally, why am I not seeing other posts raising these same questions?)
My "workaround" is to use "Managed by Printer" for printing rough prints from LR and to do all other printing from PS, especially given the noted diffs in CMM performance between LR and PS and the fact that printing from PS also supports using Photokit Sharpener for high-quality prints. Still it would be nice to understand why this is happening in LR and to be able to print "decent" prints directly from LR when it seemed appropriate.
Any insights or suggestions will be very much appreciated. Please remember to reply to my direct email address ([email protected]) in addition to your public reply to this forum.
Thank you!
/eddie

Problem with cron due to TERM

I used to work on HP-UX and schedule jobs using cronjob. TERM was initialized in .profile using following -
if [ "$TERM" = "" ]
then
eval ` tset -s -Q -m ':?hp' `
else
eval ` tset -s -Q `
fi
In cron, while executing a job, I used to call .profile to read variables. I used to do like this in cron-
0 0 * * * export TERM=""; . .profile>/dev/null 2>&1; <the actual program>
tset is not working in Solaris. cron is unable to execute due to TERM error. I tried by setting TERM=vt100 and also TERM=sun. Both failed. Any suggestion is highly appreciated.
Thanks,
bg2030

Another thing I notice is -
cron is having issue executing .profile. I mean I can run this via cron
* * * * * test.sh;However, I cannot run this -
* * * * * . .profile>/dev/null 2>&1; test.sh;If I include the .profile lin in the shell script and schedule it through cron, it is not executed. But, I can execute the same file manually.
It seems cron is having some issue with .profile. I also tried with . $HOME/.profile but it didnt work.
Is there any special setting needs to be done for cron to execute .profile.
thanks,
bg2030
Edited by: bg2030 on Jul 15, 2009 5:46 AM

Color differences between high and low res images in Illustrator pdfs

OK, I'm creating a tradeshow graphic for a client. I designed the whole thing in Illlustrator CS6. But for the proof, I used a low res image of the sky (before we purchased it). Everyone was happy. It was a low-res RGB image imported into Illustrator, then the whole thing was exported as a pdf.
Once they approved it, I purchased the high res image. RGB. Same image... just high res. I popped it into the Illustrator file and exported it in exactly the same way. But now, the image looks much more purple. The low res pdf showed it as much brighter, lighter blue.
My client prefers the lighter blue. When I look at the two images in Photoshop, they look the same (in terms of color).
So... should I be worred? Why is there such a color difference? Thanks!
I'm attaching jpgs of the pdfs just to show you the color differences.
Julie

Print Graphics: File >> Document Color Mode CMYK.
Digital Graphics: File >> Document Color Mode RGB.
The PDF presets in Illusttrator will generate CMYK PDFs or PDFs in the colorpsace Illustrator is set to, (except for smallest file size which makes RGB PDFs).
Firsst make sure you are in the correct colorspace in Illustrator before proceeding, adn make your imaeg CMYK if you are for example doing a banner for tradeshow. Backlit graphics are the only print graphics exception and should be RGB because Lambda printers actaully are native RGB.
Open your lo and hi res in Phoothsop and compare the color values by watching the info aplette in Photoshop.
When generating PDFs keep in minds that and RGB PDFs have different color than a CMYK PDF.

Good 17-19" color monitor for under $200?

I'm looking for a decent color monitor -- in terms of color fidelity and contrast ratio -- for under $200, preferably $150 or less. Is that possible? My current monitor makes pictures appear too dark when editing, even with the brightness turned all the way up. When I edit photos to make them look good on the screen, they appear washed out elsewhere (i.e., on other screens or when printed).
I'm obviously not a pro looking for top of the line stuff -- just a decent 17-19 inch monitor for editing photos in Lightroom. Thanks.

While a better monitor is always, well.....better...I'm not sure that's going to solve your problem. The issue appears to be one of color management, particularly monitor calibration. I would strongly advize investing $25 and taking a one month membership at lynda.com. There you can check out some excellent video training on this subject (and many others).
My experience is that to get anywhere close to matching prints to what you see on screen, be prepared to spend a couple of hundred bucks on calibration software and hardware. I opened this can of worms a couple of years back and it took a while to get my head around the concepts of color spaces, gamuts, soft proofing, hardware profiles etc. etc. But it was worth it in the end. I'm certanly no expert, but I have a much clearer idea of what's going on with my prints color-wise. Screen-to-print is still not an absolutely perfect match (is anyone's?), but close enough for my purposes (weddings, events, portrait photography).
I looked into getting a better monitor, but my research tells me that if I'm paying much less that $1500, the result may not be much better than what I've got (an old View Sonic GS771, a snip at $20 !!).
Seriously, lynda.com, you can't go wrong. Best money I ever spent.

What color space as base in a brand guide?

What color space forms the base of a color brand guide? How do you start in terms of color spesifications? When I look at most guides it seems that Pantone is always the base, then CMYK, then RGB and Hex? Is RGB and Hex always gonna be a dithered version of the CMYK values or is it best practise to hand pick each one to make them look as close to the CMYK as possible? Is Pantone always mentioned first in the list because that's where the designer started?
Also, is best practise to mimmick the CMYK and Pantone colors so that the RGB and hex values look like them? Seems to me that most brand guides / visual manuals are made firstly for print, then they add the screen based color spaces.
In the enclosed example I also observe that the complete values are not always listed, in many cases the Y and K is missing in the CMYK values, does that mean it doesn't contain any black, or is it simply meaning zero? It rarerly occurs with the other color spaces.

For web, email and screen in general it should always be sRGB. Then you can be fairly certain that it will display correctly (more or less) in any scenario. sRGB wil also work for print (inkjet), it's just that many colors that can be printed are out of sRGB gamut, so it's a restriction that doesn't need to be there. sRGB is a small color space that can't reproduce very saturated colors - they're just clipped. So it's better to start with a larger space like Adobe RGB or even ProPhoto.
For editing purposes you want a large color space simply to have headroom and not hit the wall at every move. The final destination may well be a smaller space, like a printer profile. The software then converts to that destination profile as it goes to the printer. You can soft proof to the printer profile to get an impression of how the final result will look.
You can print directly from InDesign, but the typical InDesign workflow is to export a finished PDF. That is where you specify a final destination profile for the whole document, whether a certain CMYK profile for offset press, or an RGB profile for screen. So you have your master InDesign file, and output PDFs for each destination. The InDesign file can contain placed RGB images in any color space, while text and graphic elements are CMYK. Then everything is converted in one go at export.
You should always go through the PDF Export dialog carefully. Use the presets, but don't automatically accept defaults. For specific purposes, ask here or in the InDesign forum, where they deal with this all the time.
For screen, under "Output" use convert to destination, sRGB, include profile. Under "Compression", things aren't as obvious as they used to be (downsample to 96 or 100 ppi), because of the new retina displays that can benefit from a higher resolution. I hold my judgement on this one.

TERM=sun-color

Similar Messages

Maybe you are looking for