Apparent bug in 3.1's handling of color labels

This ties is with [Applescipt manipulating color label|http://discussions.apple.com/thread.jspa?threadID=2645193&tstart=15] posted earlier today.
If you set the color label of an image to have no color label via the pulldown in the metadata tab of the inspector (select the first circle which will display the text *No Label* when selected) the images color label is set to the string "No Label". Confirm this by looking at the browser in column view, the third column in the default view is Label. You'll see that for colors you'll get a circle of the color and the string name of the color. You'll also notice that other images that do not have a color label simply have --
The problem arises if you select *No Label* in the search field or Filter HUD. The images labeled as *No Label* rather then the empty string will not show up in the search.
The *No Label* string can be cleared out by setting the images label to No Label via the +Command 0+ keystroke.
The Applescript command to set color labels also exhibits this behavior.

Working with events can sometimes be interesting. I concentrated my efforts more on fixing the issue than trying to determine if this is a bug or not. I modified your code slightly to filter events based on click type and I think it is working the way you intended. Let me know it is not quite right.
Attachments:
Double-click-click[2].vi ‏62 KB

Similar Messages

Apparent Bug: Adding photo to Contacts

I was editing a contact and noticed an apparent bug:
Go to Contacts --> Select a Contact (one without an assigned picture) --> Click "edit" --> Click add photo --> Select the option "Take photo" --> Take a photo.
Even after selecting use photo, it will not be added to your contacts. The contact will still show no photo. Additionally, the photo will not be added to your photos album or anything. New bug?

I have noticed this issue and and off throughout the history of my various iPhones. In iOS 4 it is certainly there, but I am honestly unsure if this is a bug with the OS, or something that is in my backups that just continues to manifest as I update/transfer my iPhone to new ones each year.
While I applaud that I have been able to do that and the relative stability, it would be GREAT if I could carry forward application data, yet delete other settings. I'd really like to start my iPhone over (as in, set it up as new and just transfer my apps and their data back to the phone,) but it is really an all or nothing proposition.
Have any of you had this issue after a reset of the iPhone? Are we all people who have carried our phone images forward? Would be curious to know...

Bug in Aperture's Color labels?

When I select an image and use the main menu to change the color label to nothing, viewing in the list view shows the label as "--" (without the quotes). When I use the sidebar to perform the same operation, the list view shows the label to be "No Label" (with the quotes). This seems inconsistent. Is this a bug?

Yes, its been around since at least version 3. While it doesn't cause a lot of problems in Aperture itself if you try to use Applescript to script the labels it causes all sorts of problems.
I reported it numerous times, keep hoping that one day it will be fixed. You can send feedback to Apple reporting this, see Aperture->Provide Aperture Feedback
regards

Let the printer handle the colors

If I select to let the printer (Xerox Docucolor 3535 using Splash 3535) handle the color management instead of Photoshop, I get good results. Otherwise the cm is done twice and I get way too much color (mostly magenta).
I'd like the same option in Acrobat. There is an option that sounds like it, but doesn't deliver the same results. How can I get that done? To test if it works, I print the same image directly from Ps(CS3) that I place into an InDesign PDF and print directly from Acrobat(9).
Thanks a lot!
Background:
Dov Isaacs of Adobe told me to let the application handle the cm but Xerox was here yesterday and they insist that the printer does the cm. Either way, I only get acceptable results if only the printer handles it.

Thanks, Mike.
So there is no option that does this only when printing, as in Ps?
I tried this:
Turned CM off in the Preferences. Then printed using "Printer handles colors" (don't know the exact term in the English version).
Result: Not the result I get from Ps when letting the Printer handle the CM. Instead I get the usual problem of too much color, too much Magenta etc.
Then I tried this (CM still off):
When printing I chose "As is (no Color Management)" instead of letting the printer handle the colors. Again, same result.
It only works from Ps so far. I don't understand why there is such a difference between the different CS3 apps when chosing and option that is supposed to let the printer hanlde the CM.
Neither Xerox nor Adobe can tell me how to solve this problem. Both say the other company's CM should be turned off and can't tell me how to turn off their own.

Possible bug - Missing click event when handling change event

Using Flex 4.5 SDK, I have a spark ComboBox and a Button next to it for applying a filter according to ComboBox selection.
I listen to both the ComboBox's change event & the Button's click event (for different functions).
When I manually delete the ComboBox text value from its TextInput (i.e. changing selected index to -1) and immediately click on the Button,
the click event-handler function is not being called and only the ComboBox's change event-handler function is executed.
(Selecting a value from the ComboBox's list and clicking on the button triggers both methods on the right order.)
There's also a state definition for the module, but it isn't being changed during these operations...
Is this a bug or a correct behavior? Am I missing something here?
Any workaround suggestions?
(I thought of listening also to mouse-down or mouse-up on the button instead, but haven't tried it yet...)
*** UPDATE ***
When using the Button's mouseDown event the behavior is as expected, so there's a simple workaround.
However, it seems to me like there's a bug with the Button's click event listener or something...
*** UPDATE #2 ***
I created a test application for that and couldn't reproduce the problem.
Then I figured out the problem and solved it.
It's a bit emmbarrasing, but I actually disabled the button (enabled=false) as in a child method of the change handling code...
(If there is no value, don't allow applying the filter - It makes sense! )
Anyway... No issue after all.
However, I choose to leave this post (and not delete it) as an example of identifying and resolving a strange behavior in a complex application.

There's no need.
Please read the section UPDATE #2.

[BUG] Problem with Error message handling in JDeveloper 11.2.1.0

Hello!
I'm Daniel from Brazil.
I have been facing a problem recently to which I see no solution. I need to use a specific component called 'Panel Label and Message' in order to nest three other components which need to be grouped together to work properly (an input text box, a LOV calling 'search button', which searchs and populates the input box, and an output text box which displays text depending on the input field). This works fine!!
The problem comes when I try to place an Access Key that should focus on the input text box part of the group component. In order to do that, I put it on the 'Panel Label and Message' component, and set the 'for' property to the input text box. This too works fine, as when I access it the component redirect the focus to the right place.
Problem is, when the user decides to this specific field (which is required) blank, JDev has problems handling the actual name of the component, and just calls it 'Component', as the screenshots below show. Apparently, for the other error messages that are handled by myself or generated by other means, it deals with the component's actual name just fine. Is there any way around this? Thanks!
'Panel Label and Message' component properties. it9 is the id of the 'Input Text' field component. Access Key set to F.
http://img.photobucket.com/albums/v82/myfireburnsblack/PropertiesErrorBug.png
Error message I get (it's in portuguese). Field has been left blank, and JDev says I have to put something in, but refers to the field as 'Component'. Any other error is handled correctly, as far as I've tested.
http://img.photobucket.com/albums/v82/myfireburnsblack/jdevError.png

Hi Daniel,
You're not the only one who has seen this: {message:id=9938606}
As mentioned in that other thread - I had tested similar use cases and it works for me.
Do you have access to https://support.oracle.com to file an SR?
John

Apparent bug in refresh

Hi,
For Kodo, if an optimistic transaction is active, and a JDO instance is persistent-dirty, passing
the instance to refresh causes the state to be reloaded from the datastore, but it also changes the
JDO state to persistent-clean. The spec calls for persistent-nontransactional. I don't know why,
since there is no apparent reason why refresh should change an instance from transactional to
nontransactional.
David

Hi Marc,
Actually, I am referring to section 5.8, table 2, first page. A refresh on a persistent-dirty
object will either make it PC or PNT depending on whether the transaction is datastore or
optimistic. These two entries in the table are the same for all three versions of the PFD.
I got an answer back from Craig Russell on my question, "why draw a distinction" between the
two. The motivation is this: For optimistic transactions, PC objects are compared (in the case of
Kodo SHOULD be compared, this is another bug that I reported) with the persistent state in the
datastore to make sure that cached persistent state is up-to-date. Since the object has just been
refreshed, it makes sense to assume that the application no longer feels the need to verify its
freshness against the datastore, so it is made PNT.
David
Marc Prud'hommeaux wrote:
>
David-
For Kodo, if an optimistic transaction is active,
and a JDO instance is persistent-dirty, passing
the instance to refresh causes the state to be
reloaded from the datastore, but it also changes the
JDO state to persistent-clean. The spec calls for
persistent-nontransactional.I believe you are referring to section 12.5.1 of the JDO PFD #2. Note
that the corresponding section in JDO PFD #1 does not state that
this should be the case, and Kodo currently only supports JDO PFD #1.
Otherwise, you are correct.
I don't know why, since there is no apparent reason why
refresh should change an instance from transactional to
nontransactional.That is a very good question -- I can't figure it out either.
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com
Kodo Java Data Objects Full featured JDO: eliminate the SQL from your code

Apparent bug in ojdbc14-10.2.0.2.0

Hi,
I believe I have discovered a bug in the current Type 4 JDBC driver for Oracle 10g. I have isolated the problem into a small program that demonstrates it. Who should I send it to or where should I post it? Would it be OK to describe the issue here, perhaps including listings?
Thx,
jh

Use your CSI to create a Service Request in Metalink with all the details.
BTW you can also share the details here. It might not be a Bug

Apparent Bug in Saving ACR Presets

I was experimenting with some Camera Raw presets for a new camera and discovered that when I saved a preset for the Detail panel, some of the values were omitted. Specifically, the preset did not save the values for Luminous Detail, Luminous Contrast, and Color Detail from the Noise Reduction section of the Detail Panel. Shown below is a preset I saved with dummy values to illustrate this problem. You can see that the three values I mentioned above are missing from the preset. Would someone please try this on their computer to see if this is indeed a bug or if I have something else going on?
I’m using Camera Raw 6.3 on a 64-bit Windows 7 computer. Photoshop version is 12.0.3x64, and Bridge is version 4.0.4.2. If this is an actual bug, maybe someone who has ACR 6.4RC could check to see if it’s still a problem in this newer version.
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.2-c004 1.136881, 2010/06/10-18:11:35        ">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about=""
    xmlns:crs="http://ns.adobe.com/camera-raw-settings/1.0/">
   <crs:Version>6.3</crs:Version>
   <crs:Sharpness>37</crs:Sharpness>
   <crs:LuminanceSmoothing>56</crs:LuminanceSmoothing>
   <crs:ColorNoiseReduction>37</crs:ColorNoiseReduction>
   <crs:SharpenRadius>+1.3</crs:SharpenRadius>
   <crs:SharpenDetail>27</crs:SharpenDetail>
   <crs:SharpenEdgeMasking>48</crs:SharpenEdgeMasking>
   <crs:HasSettings>True</crs:HasSettings>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
Thanks,
Chuck

I got a lot more - including I think the ones you're saying you're missing - when I tried it with 6.3, as shown below.
Did you check all the boxes in the dialog asking you what you wanted to save?
-Noel
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.2-c004 1.136881, 2010/06/10-18:11:35        ">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about=""
    xmlns:crs="http://ns.adobe.com/camera-raw-settings/1.0/">
   <crs:Version>6.3</crs:Version>
   <crs:ProcessVersion>5.7</crs:ProcessVersion>
   <crs:WhiteBalance>As Shot</crs:WhiteBalance>
   <crs:Exposure>-0.25</crs:Exposure>
   <crs:Shadows>0</crs:Shadows>
   <crs:Brightness>+50</crs:Brightness>
   <crs:Contrast>+25</crs:Contrast>
   <crs:Saturation>-8</crs:Saturation>
   <crs:Sharpness>15</crs:Sharpness>
   <crs:LuminanceSmoothing>40</crs:LuminanceSmoothing>
   <crs:ColorNoiseReduction>0</crs:ColorNoiseReduction>
   <crs:ChromaticAberrationR>0</crs:ChromaticAberrationR>
   <crs:ChromaticAberrationB>0</crs:ChromaticAberrationB>
   <crs:VignetteAmount>0</crs:VignetteAmount>
   <crs:ShadowTint>0</crs:ShadowTint>
   <crs:RedHue>0</crs:RedHue>
   <crs:RedSaturation>0</crs:RedSaturation>
   <crs:GreenHue>0</crs:GreenHue>
   <crs:GreenSaturation>0</crs:GreenSaturation>
   <crs:BlueHue>0</crs:BlueHue>
   <crs:BlueSaturation>0</crs:BlueSaturation>
   <crs:FillLight>0</crs:FillLight>
   <crs:Vibrance>0</crs:Vibrance>
   <crs:HighlightRecovery>0</crs:HighlightRecovery>
   <crs:Clarity>0</crs:Clarity>
   <crs:Defringe>2</crs:Defringe>
   <crs:HueAdjustmentRed>+1</crs:HueAdjustmentRed>
   <crs:HueAdjustmentOrange>+3</crs:HueAdjustmentOrange>
   <crs:HueAdjustmentYellow>+5</crs:HueAdjustmentYellow>
   <crs:HueAdjustmentGreen>-5</crs:HueAdjustmentGreen>
   <crs:HueAdjustmentAqua>-25</crs:HueAdjustmentAqua>
   <crs:HueAdjustmentBlue>0</crs:HueAdjustmentBlue>
   <crs:HueAdjustmentPurple>0</crs:HueAdjustmentPurple>
   <crs:HueAdjustmentMagenta>-3</crs:HueAdjustmentMagenta>
   <crs:SaturationAdjustmentRed>-5</crs:SaturationAdjustmentRed>
   <crs:SaturationAdjustmentOrange>-4</crs:SaturationAdjustmentOrange>
   <crs:SaturationAdjustmentYellow>+1</crs:SaturationAdjustmentYellow>
   <crs:SaturationAdjustmentGreen>+8</crs:SaturationAdjustmentGreen>
   <crs:SaturationAdjustmentAqua>-2</crs:SaturationAdjustmentAqua>
   <crs:SaturationAdjustmentBlue>-13</crs:SaturationAdjustmentBlue>
   <crs:SaturationAdjustmentPurple>-2</crs:SaturationAdjustmentPurple>
   <crs:SaturationAdjustmentMagenta>-2</crs:SaturationAdjustmentMagenta>
   <crs:LuminanceAdjustmentRed>-5</crs:LuminanceAdjustmentRed>
   <crs:LuminanceAdjustmentOrange>-3</crs:LuminanceAdjustmentOrange>
   <crs:LuminanceAdjustmentYellow>0</crs:LuminanceAdjustmentYellow>
   <crs:LuminanceAdjustmentGreen>+8</crs:LuminanceAdjustmentGreen>
   <crs:LuminanceAdjustmentAqua>+12</crs:LuminanceAdjustmentAqua>
   <crs:LuminanceAdjustmentBlue>0</crs:LuminanceAdjustmentBlue>
   <crs:LuminanceAdjustmentPurple>0</crs:LuminanceAdjustmentPurple>
   <crs:LuminanceAdjustmentMagenta>0</crs:LuminanceAdjustmentMagenta>
   <crs:SplitToningShadowHue>0</crs:SplitToningShadowHue>
   <crs:SplitToningShadowSaturation>0</crs:SplitToningShadowSaturation>
   <crs:SplitToningHighlightHue>0</crs:SplitToningHighlightHue>
   <crs:SplitToningHighlightSaturation>0</crs:SplitToningHighlightSaturation>
   <crs:SplitToningBalance>0</crs:SplitToningBalance>
   <crs:ParametricShadows>0</crs:ParametricShadows>
   <crs:ParametricDarks>0</crs:ParametricDarks>
   <crs:ParametricLights>0</crs:ParametricLights>
   <crs:ParametricHighlights>0</crs:ParametricHighlights>
   <crs:ParametricShadowSplit>25</crs:ParametricShadowSplit>
   <crs:ParametricMidtoneSplit>50</crs:ParametricMidtoneSplit>
   <crs:ParametricHighlightSplit>75</crs:ParametricHighlightSplit>
   <crs:SharpenRadius>+0.5</crs:SharpenRadius>
   <crs:SharpenDetail>100</crs:SharpenDetail>
   <crs:SharpenEdgeMasking>0</crs:SharpenEdgeMasking>
   <crs:PostCropVignetteAmount>0</crs:PostCropVignetteAmount>
   <crs:GrainAmount>0</crs:GrainAmount>
   <crs:LuminanceNoiseReductionDetail>100</crs:LuminanceNoiseReductionDetail>
   <crs:LuminanceNoiseReductionContrast>0</crs:LuminanceNoiseReductionContrast>
   <crs:LensProfileEnable>1</crs:LensProfileEnable>
   <crs:LensManualDistortionAmount>0</crs:LensManualDistortionAmount>
   <crs:PerspectiveVertical>0</crs:PerspectiveVertical>
   <crs:PerspectiveHorizontal>0</crs:PerspectiveHorizontal>
   <crs:PerspectiveRotate>0.0</crs:PerspectiveRotate>
   <crs:PerspectiveScale>100</crs:PerspectiveScale>
   <crs:ConvertToGrayscale>False</crs:ConvertToGrayscale>
   <crs:ToneCurveName>Custom</crs:ToneCurveName>
   <crs:ToneCurve>
    <rdf:Seq>
     <rdf:li>0, 0</rdf:li>
     <rdf:li>34, 22</rdf:li>
     <rdf:li>67, 60</rdf:li>
     <rdf:li>138, 144</rdf:li>
     <rdf:li>193, 204</rdf:li>
     <rdf:li>255, 255</rdf:li>
    </rdf:Seq>
   </crs:ToneCurve>
   <crs:CameraProfile>Camera Standard</crs:CameraProfile>
   <crs:CameraProfileDigest>F0D06C559756F7BD7331A9DB44BF84DD</crs:CameraProfileDigest>
   <crs:LensProfileSetup>LensDefaults</crs:LensProfileSetup>
   <crs:HasSettings>True</crs:HasSettings>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>

Apparent bug in evict

Hi,
Table 2 (the state transitions table) in the spec says that evict on a persistent-dirty instance
leaves its state unchanged. It does not say that an exception should be thrown as Kodo does. The
spec in section 12.5.1 implies that eviction may be delayed. In other words, the behavior that I
would expect, if I am correctly interpreting the murky depths of the spec here, is that evicting a
persistent-dirty instance has no immediate effect, but after the transaction completes, the instance
is then evicted. Evict marks it for eviction and this mark overrides the behavior indicated by the
transaction's RetainValues property.
If I were deciding implementation behavior, I would make all evictions inside a transaction put a
mark, even if they immediately evict the object, so that when the transaction completes, all evicted
objects are, in fact, evicted at transaction completion. So a PNT or PC object that is evicted and
reused within a transaction would get evicted again when the transaction completed. At transaction
completion, the eviction mark would be removed. As you can tell, I kind of like expected behavior
to be simply described and uniformly implemented. It makes an application programmer's life a lot
easier.
David Ezzio

David-
I believe you are correct. I have made a bug report about this:
http://bugzilla.solarmetric.com:8080/show_bug.cgi?id=124
David Ezzio <[email protected]> wrote:
Hi,
Table 2 (the state transitions table) in the spec says that evict on a persistent-dirty instance
leaves its state unchanged. It does not say that an exception should be thrown as Kodo does. The
spec in section 12.5.1 implies that eviction may be delayed. In other words, the behavior that I
would expect, if I am correctly interpreting the murky depths of the spec here, is that evicting a
persistent-dirty instance has no immediate effect, but after the transaction completes, the instance
is then evicted. Evict marks it for eviction and this mark overrides the behavior indicated by the
transaction's RetainValues property.
If I were deciding implementation behavior, I would make all evictions inside a transaction put a
mark, even if they immediately evict the object, so that when the transaction completes, all evicted
objects are, in fact, evicted at transaction completion. So a PNT or PC object that is evicted and
reused within a transaction would get evicted again when the transaction completed. At transaction
completion, the eviction mark would be removed. As you can tell, I kind of like expected behavior
to be simply described and uniformly implemented. It makes an application programmer's life a lot
easier.
David Ezzio--
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com
Kodo Java Data Objects Full featured JDO: eliminate the SQL from your code

Rich text field will not show proper font attributes! (Bug? - RTF OTF font handling)

I created two text form fields (rich text)...
In Windows 7, Write program (using it to format the rich text content)... I edited my two lines.
Line one: mix of two font sizes and a few attribute changes... pasted into the first text field perfectly.
Line two: similar to the above... pasted into the second text field but the font is appearing in bold! It is not bold in the source, nor is it preset in the text field properties! I even pasted it back into Write AND Word and it pastes as I intended it.
Why is Adobe doing this? I even tried to toggle >Text Style > bold on/off, clear formatting... these functions do not work!
If I bring up the properties toolbar (Ctrl-E), bold is toggled on but I cannot toggle it off, I can add underline, I can change the font size.
UPDATE: It seems that Adobe Acrobat is NOT reading the OTF font correctly! If I change to a different font, in the same family, the problem changes from set on bold to set on italics!
It is specifically related to the font I am using but is ONLY a problem when using Rich Text fields. In other words, the entire font family works perfectly if I inserted a text box or use the font family in any other Adobe product.
I have submitted a bug report: https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform&loc=en

Another possibly revealing clue is that when I go to Text Field Properties > Appearance tab > Text / Font, I see the entire family of this particular font. However, when editing the text in the properties toolbar (Ctrl-E), only a small sub-set of this font family appears and the attributes behave in an odd manner. Example: normal font appears as italics but if I switch on BOLD, the italic attribute is gone... and other strange attribute problems.

BUG: JSP Compiler Inconsistency in handling EL under Jdev 10.1.3.0.4.3673

I think I have a reproducible test case for exposing this problem. Follow these steps in Jdev 10.1.3 production.
1) Create new Web Project, give it a name, next
2) Select Servlet 2.3, then next
3) Check Add JSP Page, next, finish
4) Accept defaults for new JSP page, click finish
5) Open JSP Component Palette and drag Taglib Directive onto the new JSP page.
6) Select JSTL Core 1.0, click OK
7) Paste this in the body: <c:set var="bogus" value="something"/> Test: ${bogus}
8) Right click, run. The page will have this output: Test: ${bogus}
9) Modify the JSP to force a recompile, save, refresh the browser
The output will change with the EL expression evaluated properly: Test: something
The JSP compiled before oc4j starts does not behave the same as the JSP recompiled within oc4j. A bug?

Please disregard the j2ee vs. studio comment. It was because I opened and ran the same project in the studio version without recompiling the jsp under Jdev. The compiled jsp was left over from my previous run of oc4j.
Again, the problem is present in both editions.

Bug in DataConnection / XSD Schema handling with attributes

It took me one day to figure out that Dataconnection does not like importing regular schema or XML instances - they have to be wrapped in an XDP "envelope" (like what XDP output mode creates).
After getting over that hurdle - then if you have attributes with the same name on different elements - eg it crashes XFA.
This is a VERY common thing - and Adobe should not crash on this.
Also - the information model is flawed in that you need a unique instance to bind to - so how do you do repeating blocks to individual fields?
There needs to be a way to make a generic model structure element - but then assign that to multiple form fields - but each time add an index value. E.g. [box1][box2] etc.

The only solution here is to use XSLT to clean-up the mess.
I was able to finally get my xslt working so that it re-formats the xdp output into normal XML.
It should not be this hard to do all this. Ho hum.
DW

A strange bug in 10Gr2.How to handle??

Hi friends,
In Oracle 9i releases It works fine...
SQL> set serveroutput on
SQL> exec dbms_output.put_line(10*99990000*12);
11998800000
PL/SQL procedure successfully completed.
but in any 10g releases the same code gives..
SQL> set serveroutput on
SQL> exec dbms_output.put_line(10*99990000*12);
BEGIN dbms_output.put_line(10*99990000*12); END;
ERROR at line 1:
ORA-01426: numeric overflow
ORA-06512: at line 1
Please help if you have already noticed it.Or point me if I've been forgetting something.

Check out Metalink document 351965.1. This looks like your issue.

Custom Printer Presets apparent bug?

I've been using a Canon i9900 for years with Adobe products without trouble, but since about the time of my Leopard upgrade, a small annoying shift keeps occuring when trying to print without Canon or Colorsync management of color (as one normally does when Photoshop manages color). My presets are saved (and always were saved) with "Color Option" -> "Color Management" set to "None". Now, every time I reprint, the presets are overridden with "Color Management" set to "BJ Standard". Leaving the dialog and returning instantly causes this override every time. New presets also. The file "com.apple.print.custompresets.plist" seems to be replaced just fine. Deleting this file and starting from scratch is no help. The "Color Management" portion of the presets, simply isn't recalled correctly...ever.

I am seeing problems with the com.apple.print.custompresets.plist too. The presets are ignored. The plist file seems to have the right settings but the print dialog box doesn't show them.
In fact, as an example, choosing to save a new preset after turning on the duplex option for printer (from the Layout panel of the print dialog) simply undoes the duplex setting (turns it off).
Deleting the com.apple.print.custompresets.plist file does nothing. The error is occurring elsewhere presumably.

Apparent bug in 3.1's handling of color labels

Similar Messages

Maybe you are looking for