Pages: 1 2 [3] 4 5 ... 7   Go Down

Author Topic: CS4/Leopard fix for printing targets  (Read 50534 times)

djoy

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 50
CS4/Leopard fix for printing targets
« Reply #40 on: November 03, 2009, 01:28:23 pm »

Quote from: DYP
If for some reason (can't think of any) I would go the Epson route I would use a RIP.

I think you have some unresolved issues with Epson...

Either way, not interested in commercial RIPs. Limited to one printer model and a niche market ( so limited resaleability ) which makes it too high a cost to justify, and arguably not worth the price in the first place. In my own ( naturally subjective ) testing no better in quality over a well setup and profiled printer using decent drivers *cough*.

That said, I'm a keen supporter of QuadToneRIP.

Anyway, we're veering off-topic again...  
Logged

Doyle Yoder

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 519
CS4/Leopard fix for printing targets
« Reply #41 on: November 03, 2009, 02:05:37 pm »

Quote from: djoy
That could have been it, though I thought it was a little more serious than that, I'm trying to find the release notes of the new ColorMunki software to check those as well. That aside, if it's just the issue detailed above, then it's not an issue. I felt sure I read somewhere there was an issue with v4 and Colorsync in Snow Leopard.

Anyway, it's off topic, so, moot.

Blue Eye Pro has no problem with creating and SL has no problem using Version 4 profiles. I have not heard of any problem with ColorEyes. And have no problems with version 4 printer profiles.

Doyle
Logged

Ernst Dinkla

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 4005
CS4/Leopard fix for printing targets
« Reply #42 on: November 03, 2009, 03:08:40 pm »

Quote from: johncustodio
The issue is not confined to Leopard and Epson drivers. I'm using Tiger and an HP Z3100 with CS4 and I had the same problem. The workaround solved it. I read about it in Amadou's blog a few months ago.
-John

In what way could there be the same problem?  The Z models use a separate application (Printer Utility>Color Center) that triggers the target printing and if I'm not mistaken the targets are stored on the printer like the calibration target is. At least I tried to find them in the Color Center map for other reasons and they are not there. The software doesn't even ask to switch off CM as there shouldn't be a channel that is affected by CM. The only treatment it gets is the ink limitation etc of the media preset.  For the profile creation process after that there shouldn't be any interference of Adobe ACE or Apple Colorsync either.

Printing from Photoshop and the created profiles used there is another issue but as far as I understand it that should work well with tagged images. If you want to print targets with Photoshop for other profile creation programs then I can understand there is an issue. For example with QTR profile creation.

HP's optional APS does have the targets in the program map and it could use a driver channel that interferes with Colorsync but I have not seen a report of problems there.

Standing at the sideline here as I print from Qimage in a Windows environment with a Z3100 and Z3200. BTW an application where you can switch off CM and then it is really OFF. The way I print the QTR targets for B&W profiles.



met vriendelijke groeten, Ernst Dinkla

Try: http://groups.yahoo.com/group/Wide_Inkjet_Printers/












Logged

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
CS4/Leopard fix for printing targets
« Reply #43 on: November 03, 2009, 04:36:00 pm »

Could this be a situation where it makes sense to leverage diagnostics by recourse to how these processes are managed between Windows XP (or perhaps Vista if it had no issues - I don't know I never adopted it) and the Windows versions of the same Epson drivers versus what happens or doesn't happen in the OSX environment? Perhaps if there were a way of drilling down such a comparison, would it help to throw light on the question of what aspects of the problem may be lodged with Colorsync versus what aspects with the Epson drivers? I ask these questions because there seems to be a view from Jeff that the problem is Colorsync, but a view from Andrew that the driver could also be involved; as well, it has intrigued me for some time now why using Epson professional printers with Windows appears to be more seamless than with OSX, so perhaps some cross-comparison between the technologies may help to confirm where the real solutions need to be implemented.

This episode also raises, yet again, a real question about why these several companies can't sit together and make sure that before they release crititcal software it will at least perform the most basic functions correctly. It's hard to believe that Apple, Epson, Adobe and if the situation were to arise Microsoft rather than Apple, would be hauled before any kind of anti-trust proceeding on such technical collaboration, because they mainly operate in different niches of the industry and could hardly be accused of stifling competition between themselves for conspiring to achieve technical coherence of their various products in aid of all their consumers. Why is this too much to expect?
« Last Edit: November 03, 2009, 11:18:52 pm by MarkDS »
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

Doyle Yoder

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 519
CS4/Leopard fix for printing targets
« Reply #44 on: November 03, 2009, 04:56:17 pm »

The big question why do the Epson drivers handle the call from PS No Colormanagement differently than PS Manages Color. These two calls should give the same reaction in the driver, No Colormanagement. The Canon iPF drivers handle both these calls exactly the same, No Correction.

That is why I conclude there is clearly something wrong with the Epson drivers.

Doyle
Logged

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
CS4/Leopard fix for printing targets
« Reply #45 on: November 03, 2009, 05:10:13 pm »

Quote from: DYP
The big question why do the Epson drivers handle the call from PS No Colormanagement differently than PS Manages Color. These two calls should give the same reaction in the driver, No Colormanagement. The Canon iPF drivers handle both these calls exactly the same, No Correction.

That is why I conclude there is clearly something wrong with the Epson drivers.

Doyle

I'm not convinced either contention is correct. No colour management in PS means Photoshop isn't managing colour - in which case the driver is managing colour, unless it is also switched off. These are separate functions in each software. I have no idea what goes on with Canon iPF drivers because I print with an Epson 3800, but if the Epson driver is correctly specified for Windows, it would seem counter-intuitive to me that Epson would be unable to correctly specify the same driver for Mac OSX - they have AT LEAST as much of a commercial interest in getting it right for Mac as they do for Windows given the high percentage of their clientele using their printers on Mac operating systems.
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

Alan Goldhammer

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 4344
    • A Goldhammer Photography
CS4/Leopard fix for printing targets
« Reply #46 on: November 03, 2009, 05:18:01 pm »

Quote from: MarkDS
Could this be a situation where it makes sense to leverage diagnostics by recourse to how these processes are managed between Windows XP (or perhaps Vista if it had no issues - I don't know I never adopted it) and the Windows versions of the same Epson drivers versus what happens or doesn't happen in the OSX environment?

This episode also raises, yet again, a real question about why these several companies can't sit together and make sure that before they release crititcal software it will at least perform the most basic functions correctly. It's hard to believe that Apple, Epson, Adobe and if the situation were to arise Microsoft rather than Apple, would be hauled before any kind of anti-trust proceeding on such technical collaboration, because they mainly operate in different niches of the industry and could hardly be accused of stifling competution between themselves for conspiring to achieve technical coherence of their various products in aid of all their consumers. Why is this too much to expect?
Windows Vista worked fine with my R2880; never had a problem in printing.  Upgraded to Win7 two weeks ago and printed fine (though the print dialogue box said the printer was busy when it wasn't but that was cleared up by downloading the latest Win7 driver).  Microsoft clearly makes their OS available to printer vendors so that drivers can be checked and updated without a problem.  It's not clear why Apple is encountering the snafus that this thread is discussing other than they are not being as transparent as need be.  I don't think that cooperation between Apple and printer manufacturers raises any antitrust issues in the same way that some Microsoft practices have.  I've been a happy PC user since day one and have not had any problems as things migrated from DOS -> Win3 -> XP -> Vista -> Win7.  All the hardware worked as promised.

I guess I'll begin working on my C++ programing skills and apply for a job with Apple to clean up this mess!!!!
Logged

Doyle Yoder

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 519
CS4/Leopard fix for printing targets
« Reply #47 on: November 03, 2009, 05:24:32 pm »

Quote from: MarkDS
I'm not convinced either contention is correct. No colour management in PS means Photoshop isn't managing colour - in which case the driver is managing colour, unless it is also switched off. These are separate functions in each software. I have no idea what goes on with Canon iPF drivers because I print with an Epson 3800, but if the Epson driver is correctly specified for Windows, it would seem counter-intuitive to me that Epson would be unable to correctly specify the same driver for Mac OSX - they have AT LEAST as much of a commercial interest in getting it right for Mac as they do for Windows given the high percentage of their clientele using their printers on Mac operating systems.

No, there is a separate PS call, Printer Manages Color. This should be the only selection that allows the driver to managing color. All functions in the driver should be available with this call including No Colormanagement.  

It has always appeared that Apples desire in the new printing path is that when Application Manages Color or in the case of PS No Color Management that the printer drivers will turn off CM with no CM options available to the end user other than adjustment sliders. I believe any printer driver not following this is not coded correctly for Apples new printing path. Likewise any printer driver that defaults to colorsync instead of No CM is likewise coded wrong.

Doyle
Logged

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
CS4/Leopard fix for printing targets
« Reply #48 on: November 03, 2009, 06:14:07 pm »

Quote from: DYP
No, there is a separate PS call, Printer Manages Color. This should be the only selection that allows the driver to managing color. All functions in the driver should be available with this call including No Colormanagement.  

It has always appeared that Apples desire in the new printing path is that when Application Manages Color or in the case of PS No Color Management that the printer drivers will turn off CM with no CM options available to the end user other than adjustment sliders. I believe any printer driver not following this is not coded correctly for Apples new printing path. Likewise any printer driver that defaults to colorsync instead of No CM is likewise coded wrong.

Doyle

The way the Windows implementation works is that in Photoshop Print Preview, if you select Printer Manages Colour, then Photoshop is not managing colour. However, within the Epson driver there are colour management options from which the user selects, as to HOW the printer will manage colour. This is accessed either from Page Set-Up in the Photoshop Print Preview or from Preferences when the printer driver is called-up after one clicks on Print.

I don't understand what the first sentence of your second paragraph means, so the rest of it doesn't click in my mind. Either the printer or the imaging application must manage colour unless colour management is intentionally disabled in both, say in order to print profiling targets - the case at hand here. The imaging application and the printer driver should be independently user-controllable, and the operating system should respect that. These companies need to cohere enough to make it happen that way.
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
CS4/Leopard fix for printing targets
« Reply #49 on: November 03, 2009, 06:28:11 pm »

Quote from: Alan Goldhammer
Microsoft clearly makes their OS available to printer vendors so that drivers can be checked and updated without a problem.

I don't think it works that way. A Windows OS has millions upon millions of lines of code and it's proprietary. I believe they make an SDK available which is supposed to allow third party applications and drivers to be crafted coherently. I believe this is standard industry practice.
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

Alan Goldhammer

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 4344
    • A Goldhammer Photography
CS4/Leopard fix for printing targets
« Reply #50 on: November 03, 2009, 06:46:49 pm »

Quote from: MarkDS
I don't think it works that way. A Windows OS has millions upon millions of lines of code and it's proprietary. I believe they make an SDK available which is supposed to allow third party applications and drivers to be crafted coherently. I believe this is standard industry practice.
Correct; I was typing to fast and multitasking.  Years ago when Win 3 was the OS, I actually wrote some applications (mainly games for my daughters) and fooled around with the SDK.  Fun but not my real life job; future versions of Windows grew in complexity to eliminate the fun factor.
Logged

djoy

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 50
CS4/Leopard fix for printing targets
« Reply #51 on: November 03, 2009, 07:14:48 pm »

As I understand it, Apple's OS-X printer pipeline is the CUPS system and Gutenprint (formerly GIMP-print) which are open-source, so the driver writers should be able to get all the information they need on interfacing with that...

My understanding of this problem as explained so far, is that Colorsync will not allow data through it without applying some form of colour management to it, the straight-through path has been disabled, and Colorsync sits between the application and the printer driver, so if you want to talk to the printer driver, you have to talk to Colorsync. This is I believe Jeff Schewe's position? and I think some of what Andrew Rodney has posted supports this, though he theorizes that there may be driver issues also.

DYP claims that only the Epson driver is at fault, because he believes the Canon driver works as he expects it to. With no disrespect to DYP I'm not sure of his credentials or how he qualifies this other than a subjective evaluation, perhaps with a few more reports from Canon users we could build a consensus? It might help highlight the base issue, and if it is Colorsync, Canon and HP users have as much to gain as Epson users. To my mind, if the Canon driver must also be accessed through Colorsync it would therefore subject to the same issue.

The comparisons with Windows printer pipelines isn't really fair or useful I feel, they're very different, Windows can't do 16 bit printing through it's pipeline ( unsure about Windows 7 ), OS-X has 16 bit wide pipelines... they're different technologies and each platform will be written separately with only a few base similarities.

So far the only people who've not really said anything, or been involved, is Apple... I hope you guys are having some luck putting pressure on these companies to look at this.
Logged

Wayne Fox

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 4237
    • waynefox.com
CS4/Leopard fix for printing targets
« Reply #52 on: November 03, 2009, 08:44:34 pm »

Seems this is getting blown a little out of proportion.  Some thoughts ..

This problem has existed for a very long time, and workarounds have existed for a long time.

The problem affects an incredibly miniscule number of mac users ... I'm guessing less than one in 10,000 ... probably even a lot fewer than that.

It isn't a major printing glitch. It's not like Mac printing is broken.  Normal printing using CS4/leopard/snow leopard functions just fine, and output is fine.  Out of all the media being printed by Macs every day on Epson printers, how much of that is actually targets for profiling?  And of course this is targets for machines not using a RIP.  Saying the affected output is miniscule is an overstatement.

the ONLY thing affected is trying to print an unmanaged image directly to a printer.  What percent of mac users actually need to do this?  sure on this forum it's pretty commonplace, but outside of our little world it's really quite rare.

I don't know who is to "blame" but to me that's a pointless exercise.  There is no conspiracy here, just an extremely rare problem occurring to an amazingly small number of Mac users, with lots of documented work a rounds.  My original post wasn't in reference to the work around or bringing this issue to light ... I myself was very involved in the original thread and was probably the first to verify what Ryan was observing.  He, myself, and others have been working around this problem for some time.  Because the problem affects so few users, no one paid any attention, and unfortunately we don't have any inside pipeline to any of these companies to get them to listen.

The real problem seems to stem from miscommunication between parties as well as perhaps some assumptions.  For example, I wonder if any of the  OS X and ColorSync engineers are aware of how critical it is to be able to send an unmanaged file to a printer for a few very specialized users.  While we can criticize apple, what they have done with ColorSync has actually made it relevant to the OS and their own applications.  For example you can actually print from iPhoto now and easily apply a profile to get decent results ... something very difficult to do before leopard.  It seems the OS is simply assuming data pushing through it as been "color managed', and if not attempts to do so.  For nearly all applications and users this isn't necessarily a bad thing.  In this one small isolated instance there is an issue.  Obviously using the null profile method tricks the OS.  But the entire premise of the Mac is to simplify things for the user, so the assumption, while perhaps problematic in this very rare case,  is somewhat valid in the context of the philosophy of the Mac and the Mac OS.

Thanks to Mark some engineers are actually listening, and now understand this very remote issue.  With feedback from people like Mark, Eric, Jeff and others, maybe the annoyance will go away.   But in the meantime the explanation of why the workaround actually works provides some confidence in the accuracy of the targets.  I have tried several workarounds before, but I was never completely confident in them.  I found myself always reverting to using an old OS and and old versions of Photoshop to "verify" them ... I finally gave up and just resorted to doing that in the first place.  this left me without a good way to profile my 7900.  Targets looked OK, but I never trusted them so I stuck with papers that had good profiles available from other sources.  I've been asked to test some new papers from a vendor meaning I have to build profiles, I'm a little more confident now that one of the workarounds I've tried before is actually valid ... which means I can actually try them on my 7900

Logged

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
CS4/Leopard fix for printing targets
« Reply #53 on: November 03, 2009, 10:25:30 pm »

Quote from: djoy
The comparisons with Windows printer pipelines isn't really fair or useful I feel, .

When I made this suggestion, I didn't have in mind any kind of beauty contest or equity considerations between operating systems - that's not what it was about. It's about seeing for purposes of analysis whether one can leverage information from something that works to understand better why something else with a number of similar attributes doesn't - for the specific intention of obtaining a non-managed profiling target. Whether it would be a useful avenue of investigation or not I do not know - I only asked the question - those who have the credentials in both operating systems can perhaps provide some insight.
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

madmanchan

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2115
    • Web
CS4/Leopard fix for printing targets
« Reply #54 on: November 03, 2009, 11:13:27 pm »

Hi Wayne, I think that's a fair characterization. One of the things I wanted to understand when I dove into the problem was whether a workaround existed that would be robust. Some workarounds (including ones I've used and suggested in the past) are fragile in that they depend on driver versions and/or OS versions (e.g., they work with Leopard, but not Snow Leopard, or the other way around). Other workarounds seem like they ought to work, but don't for highly technical reasons (e.g., if your working space in PS is "Adobe RGB (1998)" and if you chose "Working RGB - Adobe RGB (1998)" from the Printer Profile popup, seems like that should be the same as just choosing "Adobe RGB (1998)" from the same popup, right? But it's not, and you will get the wrong target printout if you do the former).

For folks on the Mac who wish to print targets, it's bad enough that we need workarounds. It would be even worse if we had to say, "ok, if you have this printer, that driver, and this OS version, then use this workaround ... and if you have that printer, this other driver version, then use this other workaround ..."

In other words, if we're going to have to deal with a workaround, the saving grace is to have a single one that can be used reliably and independent of the OS version, printer model, and driver version. (Unfortunately, I cannot claim for sure that the proposed workaround in the article has these desirable properties. But it appears to, and based on the technical understanding of what goes on within the ColorSync pipeline, I believe it does for the time being ...)
« Last Edit: November 03, 2009, 11:15:22 pm by madmanchan »
Logged
Eric Chan

na goodman

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 418
CS4/Leopard fix for printing targets
« Reply #55 on: November 03, 2009, 11:24:17 pm »

Well, I for one do appreciate a concrete workaround. And thank you Mark and Eric for your time and effort you have put into this problem. It has gone on for a long time. My solution was to leave CS3 on my system and print my targets out from there, even though my work is done in CS4. Hopefully one day it will all be sorted out. Again, thank you for the time you have put into this problem, it is indeed appreciated.
Logged

Ernst Dinkla

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 4005
CS4/Leopard fix for printing targets
« Reply #56 on: November 04, 2009, 04:47:31 am »

Quote from: Wayne Fox
I don't know who is to "blame" but to me that's a pointless exercise.  There is no conspiracy here, just an extremely rare problem occurring to an amazingly small number of Mac users, with lots of documented work a rounds.  My original post wasn't in reference to the work around or bringing this issue to light ... I myself was very involved in the original thread and was probably the first to verify what Ryan was observing.  He, myself, and others have been working around this problem for some time.  Because the problem affects so few users, no one paid any attention, and unfortunately we don't have any inside pipeline to any of these companies to get them to listen.

The real problem seems to stem from miscommunication between parties as well as perhaps some assumptions.  For example, I wonder if any of the  OS X and ColorSync engineers are aware of how critical it is to be able to send an unmanaged file to a printer for a few very specialized users.  While we can criticize apple, what they have done with ColorSync has actually made it relevant to the OS and their own applications.  For example you can actually print from iPhoto now and easily apply a profile to get decent results ... something very difficult to do before leopard.  It seems the OS is simply assuming data pushing through it as been "color managed', and if not attempts to do so.  For nearly all applications and users this isn't necessarily a bad thing.  In this one small isolated instance there is an issue.  Obviously using the null profile method tricks the OS.  But the entire premise of the Mac is to simplify things for the user, so the assumption, while perhaps problematic in this very rare case,  is somewhat valid in the context of the philosophy of the Mac and the Mac OS.

Wayne,

While you consider it as a positive development, the auto/black-box/overall color management, I wouldn't like it at all. It asks for far more communication between the OS, applications and drivers than simpler less user friendly concepts. A complex structure bound to fail somewhere like we have seen. While you think just a small group of printer users is harmed by it, I think far more are and they do not follow these lists as they trust the companies' "you push the button, we do the rest" philosophy.  There are a lot of cheap colorimeter/scanner profiling packages. There are the profile creation shops where you can send your targets. The crowd that uses QTR or some curve adaptions to print B&W from Photoshop (I have not seen the article mentioned yet on the Digital B&W list). There are the precooked profiles on the paper manufacturer's and distributor's sites. Can you still trust the profiles or the output? We all know this isn't easy stuff to learn; color management, profile creation, and now somewhere someone has thrown in some spanners too.

When a simple amateur prints his phone pictures in streams like that there are 3 companies to make it easy for him, they all implant auto features in their software and they all have to take care that the two other companies' features are neutralised when their feature is active. It is a dangerous scenario, the more when they try to protect the user by making the task as simple as it can be without any feedback on the choices made.

I return to Qimage. In its color management settings Mike added some years ago the auto-assinging feature too. For the untagged images. When no profile is assigned, the EXIF data do not give an indication, then it will assign sRGB as the default (he had AdobeRGB first till I suggested that sRGB would fit better in cases like that, just statistically better and fitting old/odd spaces also better). It can make the wrong guess, that has been discussed. That feature can be switched off. It can get another color space instead of the sRGB default. It is switched off when Qimage's total CM is switched off.

There are three general settings for Qimage's CM: 1/ Qimage CM on, 2/ Printer CM does the job (Qimage CM off, assigned image profile information goes through), 3/Qimage CM off (nothing is done in Q's CM and only RGB data goes through). Changing them does not switch the driver's CM automatically in the opposite conditions. Less user friendly but much more transparent. Consistent for the odd workflows of target printing and general NON-CM workflows like when you do a P2P conversion in Photoshop and feed the image to Qimage. Consistent in the normal workflow. If there is a flaw in your settings like double profiling you can detect that.

There is nothing lost in user friendly software with one extra choice available in the three components of that chain: CM off, CM off, CM off.  Like the OFF button on the TV can be user friendly :-)



met vriendelijke groeten, Ernst Dinkla

Try: http://groups.yahoo.com/group/Wide_Inkjet_Printers/
« Last Edit: November 04, 2009, 04:50:42 am by Ernst Dinkla »
Logged

eronald

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6642
    • My gallery on Instagram
CS4/Leopard fix for printing targets
« Reply #57 on: November 04, 2009, 08:31:25 am »

I think we should be thanking Eric for describing a workable workaround. This is the first time I have ever seen somebody devote so much thought to defining what "workable workaround" might mean

Maybe some diagnostic tools should get distributed that allow any user to check whether profiles are being applied in a printpath, and by which application.

Edmund

Quote from: madmanchan
Hi Wayne, I think that's a fair characterization. One of the things I wanted to understand when I dove into the problem was whether a workaround existed that would be robust. Some workarounds (including ones I've used and suggested in the past) are fragile in that they depend on driver versions and/or OS versions (e.g., they work with Leopard, but not Snow Leopard, or the other way around). Other workarounds seem like they ought to work, but don't for highly technical reasons (e.g., if your working space in PS is "Adobe RGB (1998)" and if you chose "Working RGB - Adobe RGB (1998)" from the Printer Profile popup, seems like that should be the same as just choosing "Adobe RGB (1998)" from the same popup, right? But it's not, and you will get the wrong target printout if you do the former).

For folks on the Mac who wish to print targets, it's bad enough that we need workarounds. It would be even worse if we had to say, "ok, if you have this printer, that driver, and this OS version, then use this workaround ... and if you have that printer, this other driver version, then use this other workaround ..."

In other words, if we're going to have to deal with a workaround, the saving grace is to have a single one that can be used reliably and independent of the OS version, printer model, and driver version. (Unfortunately, I cannot claim for sure that the proposed workaround in the article has these desirable properties. But it appears to, and based on the technical understanding of what goes on within the ColorSync pipeline, I believe it does for the time being ...)
Logged
If you appreciate my blog posts help me by following on https://instagram.com/edmundronald

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
CS4/Leopard fix for printing targets
« Reply #58 on: November 04, 2009, 09:33:35 am »

Quote from: Wayne Fox
The problem affects an incredibly miniscule number of mac users ... I'm guessing less than one in 10,000 ... probably even a lot fewer than that.
It isn't a major printing glitch.

This one problem, I’d fully agree. I’m actually pleasantly surprised by the article and number of posts here on this one issue (it shows this site has some pretty advanced users). But this is not the only problem printing. We’ve seen issues where hitting print sent the job into outer space and never to the printer. We’ve seen a problem with Advanced B&W where one has to use Adobe RGB (1998), we’ve seen issues with a small area of red in color space would band etc.

I agree that this one issue, printing targets isn’t a hill worth dying on. But there’s a history of printing issues with the key players discussed here (who I’ll simply refer to as AAE <g>).
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
CS4/Leopard fix for printing targets
« Reply #59 on: November 04, 2009, 10:00:28 am »

Quote from: digitaldog
This one problem, I’d fully agree. I’m actually pleasantly surprised by the article and number of posts here on this one issue (it shows this site has some pretty advanced users). But this is not the only problem printing. We’ve seen issues where hitting print sent the job into outer space and never to the printer. We’ve seen a problem with Advanced B&W where one has to use Adobe RGB (1998), we’ve seen issues with a small area of red in color space would band etc.

I agree that this one issue, printing targets isn’t a hill worth dying on. But there’s a history of printing issues with the key players discussed here (who I’ll simply refer to as AAE <g>).

Andrew, I've taken an interest in this thread, because I have for some time been contemplating a general move over to Mac. I'm on Windows right now and I'm actually quite agnostic about platforms - when it becomes incrementally more attractive to switch I probably will, but one of the things which holds me back is the collection of printing issues involving how AAE play together or don't. I have tremendous admiration and respect for how Eric, with his extremely busy professional work schedule, nonetheless  developed an ingenious workaround in this particular instance, and for the roles of Mark Dubovoy and Jeff Schewe in getting the issue on the table. The point Wayne made about the relative size of the profile-making clientele *grosso modo* may be statistically substantiated, but to me is not the most relevant consideration. Firstly, I think it may not be so miniscule, but more importantly, whatever the number affected - it is not insignificant, it is a generic function in its own right which deserves to work properly, the same can be said of any other outstanding problems affecting the cohesiveness of the print path between the concerned softwares, and I can't believe these glitches would be unavoidable, if only the companies concerned would make it their business to achieve a higher level of co-operation in the interest of the consumers of their products. This discussion reinforces my interest in how they can be exercised to do this, so going forward the pain can be largely avoided.

Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."
Pages: 1 2 [3] 4 5 ... 7   Go Up