Jump to content

mac_heibu

Members
  • Content count

    821
  • Joined

  • Last visited

About mac_heibu

  • Rank
    Advanced Member

Recent Profile Visitors

1,126 profile views
  1. mac_heibu

    Color Bug?

    As I said, no answer possible. Please decide in first place, what you want us to answer. As I told you, you changed your question very often during the discussion (RGB values, corresponding CMYK values, CMYK important or not — and if: why asking about RGB values and show us CMYK values without saying/know, how they were achieved? As I said: We would need at least(!) the Publisher page, which contains the element you showed in your last GIF. Otherwise, as I said, no answer possible.
  2. mac_heibu

    Color Bug?

    The values in your GIF are showing CMYK values, which are massively to high! Since your document is a RGB document, which you hopefully(!) exported correctly — and following your intentions — using the correct color space and colour profile, it is completely up to Kindle to convert correctly. An ink coverage of that height is definitely not correct, but this is not under your responsibility. Before going on in this discussion, we should clear some thing up! You are talking about a „Designer“ page, which is „cut and pasted“ into Publisher. Your sample file is no „Designer“ file but a „Photo“ file. And: Did you try not to copy and paste, but to place the image? Didn’t we talk about RGB values (R=0/G=0/B=0) up to now? Didn’t you tell us, the CMYK values are not so important, because the book is published online? Why do you show us CMYK values? How were these values achieved? Which conversion profile was used? In short: To investigate the „issue", it is necessary to have a look at the exact page, where the animated GIF was taken from. to know, which steps were undertaken and which colour profile was used to convert the RGB document to CMYK, Otherwise, no valid statement is possible.
  3. mac_heibu

    Color Bug?

    @Glyphs: Look at the attached sample files: 1 AffFoto file, 1 AffDesigner file, 1 AffPublisher file and the exported PDF. The black areas are defined as RGB 0/0/0 (document profile sRGB), placed in Publisher (RGB document, sRGB profile) and exported as sRGB PDF. The colour are and remain RGB 0/0/0. Your sample document is a publisher document, with placed pixel(!) layers. Exported as PDF and opened in Acrobat Pro, the blacks show RGB 0/0/0. Exported as a RGB TIF and opened in Photoshop the blacks are RGB 0/0/07. So: I can’t see a problem. @eluengo: In most cases your approch is ok. But even if the export is a printsble PDF, it should be (and is!) possible to create the document in RGB and leave colour conversion to the output routines of Publisher. The biggest caveat is black text in images (as is in the initial posters document) will end up as multi-colour-black in the PDF output and that normally is unwanted. Black_Test.zip
  4. mac_heibu

    Color Bug?

    Tag the images with sRGB, measure the colour values, create a RGB Publisher document with the same colour profile and use the exact same black value as used in the image.
  5. mac_heibu

    Color Bug?

    No, your assumption is wrong. First: Neither Photoshop, nor Illustrator, nor InDesign does this – or bette:r can do this. And Publisher can’t do it as well. Why? If you set RGB colours to 0/0/0, what leads you to the opinion, that the corresponding CMYK values should be 100/100/100/0? There can’t be a simple correspondence between RGB and CMYK, because of the „K“. You would be right if we didn’t deal with CMYK, but with CMY. In this case there would exist an unambiguous conversion from RGB to CMY. Since print colours need to add the „K“, every RGB color now has literally thousands of „correct“ corresponding CMYK colours. Which is the „expected and needed“ correct one? This depends on many facts: printing paper colour and quality, ink consistence, printing speed and, and and. The correspondence between RGB and CMYK colours can’t be a simply mathematically conversion (because of the „over-determined“ ambiguous CMYK system), but follows complex conversion tables stored in the used colour profile, which have been established by evaluating thousands of sample print outs. These conversion tables are different for example for different printing papers of different ink coverage requirements in different printing scenarios. Publisher has to use sort of an intern colour profiling to display corresponding RGB/CMYK values. Which ones are used is – as far as I know – not known. That is, why I don’t think, your workflow is really streamlined and secure. The RGB black of the images (and the text within the images!!) has to be converted to CMYK, and since the black is RGB black, there will be no way at all to output a K=100 black as – for example –is required for black text. But that is a different subject …
  6. There is a pinned thread for localization issues. You should post this there.
  7. You are using the wrong handle! The outer handle right bottom of the text filed resizes the box and the text within. The inner handle directly in the bottom right edge resizes the text frame and not the text.
  8. You did read my posting? Doesn’t seem so. The document "Geez Colour Settings.afpub“ is set up as an RGB document, „New File Colour Settings.afpub“ uses CMYK colours. Use „File/Document Setup“ to correct this. So, no bug at all, but simply improper usage.
  9. Don’t understand, what you want to say. Look at this screencast:
  10. This seems to be simply the difference between RGB and CMYK color models, which you can choose, when starting s new document or in document setup.
  11. Look at this. Sample Publisher file attached too. sample.afpub
  12. Draw a line, open the „Stroke“ panel and look form the arrow heads:
×