Jump to content

Lagarto

Members
  • Content count

    407
  • Joined

  • Last visited

Everything posted by Lagarto

  1. Certainly not. Did you get this with the mentioned CMYK values?
  2. Colors are complex. How badly were they tinted -- ever so slight cyan tone can be expected with these values, but it also depends on paper, and naturally on viewing conditions. If you want to have absolutely neutral grays, you should use mere K values.
  3. Here's a screenshot of your Affinity job exported as PNG (that is in RGB color format with embedded profile), and JPG (in CMYK color format with embedded profile) from Designer, and opened in Photoshop using the embedded color profiles. They look pretty much the same even here when viewed on a laptop supporting a color gamut well beyond sRGB, with a calibrated display, so if you produce the print files properly, I'd say that it is the printer's fault if you do not get expected results. As you can see here, the CMYK values of the original are untouched in the JPG file.
  4. If you export from CMYK working space, your JPG file will be in CMYK format. PNG will not, as CMYK is not supported in this format. To force the JPG into RGB format you need to specify so in the export settings. When you convert an RGB 0,0,0 to CMYK, it will happen according the working space color profile, and here also the default RGB color space (as defined in the Preferences > Color) affects the caluclation, and when using US Coated (Web) v2 it will be approximately the same disregarding the application. E.g. in Affinity Publisher you would get C72, M68, Y67, K88 and InDesign you would get C75, M68, Y67, K90. The CMYK value you mention (C60,M52,Y52,K21) is for the RGB 101, 101, 100, not 0, 0, 0. The fact that you get more C than other components is that rich black typically contains more cyan to get proper deepness. Converting any color from one color space to another without an explicitly stated profile is nonsense, so you should not trust on any conversion values that you get on the referred site. EDIT: Sorry, I misread your initial values, but what is said above applies also to gray values like 100, 100, 100.
  5. Having spent some more time with this, I must say I have not become any wiser, and I am now totally confused on how formatting is applied in Publisher. When I tested this with a set of styles I had created myself, the "based on" mechanism seemed to be the trigger for making locally formatted bold and italics getting lost when changing the paragraph style, but now that I have played with this for a while, it does not seem to be so. I still do not understand the logic behind the Publisher way of doing this, but it certainly deviates from InDesign and from QuarkXpress, and the way it works now in Publisher would be a catastrophe for the kind of workflow I typically have, not anchoring local formatting with character styles but trusting that local formatting always stays no matter what paragraph style I apply to it, unless I deliberately force the applied style to reset overrides. Not so in Affinity Publisher. instead, at least apparently more or less randomly local overrides sometimes seem to be retained and sometimes lost. It is probably related to "based on" style property, but I have not managed to find out how exactly, and have not managed to get the mechanism work consistently and reliably. I have tested this by exporting finished, perfectly styled layouts in RTF format from InDesign and importing them in Word, QuarkXPress and Affinity Publisher, and the result is that Word and QuarkXPress keep all local formatting similarly as InDesign while Publisher messes it all up. I am not sure if this is something that is now broken but has previously worked as expected, as when I have previously tried simulating the workflow I typically have (applying beforehand created paragraph formatting by using tags), I did not notice that local formatting would have been lost in the process. But as said, it seems to happen a bit randomly, so who knows. As it is now, it is more or less an obligatory step to freeze local formatting by using character styles. EDIT: In case it is not clear from the context, what is said above is related to simple change of paragraph styles by using Text Styles palette, not using any of the special commands in the context menu.
  6. Yes, I can see implications of it, but isn't this still a problem of failing to update the status of the formatting of all characters to [No Style], after this operation has factually been applied? I mean that if you select all characters of the affected paragraph and manually apply [No Style] character "style" then the duplicate styling disappears [e.g. "Heading 1 + Heading 1" becomes "Heading 1"). It does not seem that applying [No Style] actually changes anything else than the status flag, so "Apply 'Paragraph Style' and Clear Character Styles" seems to clear all character formatting, both local and character style based, even if it fails to set the character style [No style] state. See attached an example of how using "Apply 'Heading 1' and Clear Character Styles" for the oddly formatted heading clears both the local and character style based formatting. The result is "by design", I think, but the command is poorly named, and formatting status not correctly set. Or who knows, my brain already hurts... paragraph_and_character_styles_test_edited.afpub EDIT: I forgot the effect of based on "Base", so actually what the command says to do is what it actually does: it applies the paragraph style (which may or may not remove all local character formatting, depending on how the style is defined), and removes character styles. But this is not too intuitive. But this can be seen if you detach all styles from the "Base" style. After that, using "Apply 'Heading 1' and Clear Character Styles" does not remove italic local formatting from the heading but just returns its point size and capital formatting as dictated by the paragraph style. Complex... Anyway, the actual problem with this feature is that it does not correctly set the [No Style] character style formatting status. The question is, is "Apply 'Paragraph Style', Clear All" then actually a different operation and worth a separate command? This seems too complicated, already! EDIT 2: ...and answering myself: no it is not. Italic formatting is defined differently in Affinity Publisher, but if Italic is turned off or on (rather than left in indeterminate state) in the paragraph style, this command does basically what the InDesign command does: applies the paragraph style and clears local overrides and character styles, that is, "Apply Paragraph Style, Clear All". It may of course be a bit redundant to say "Clear All" (assuming that applying of a paragraph style already implies clearing of local overrides, and therefore mentioning just about clearing of character styles), but at least it is more intuitive and user-friendly.
  7. Yes, something like this (screenshots from CorelDRAW, which besides of this also allows moving the transform origin visually): As it is, the easiest workaround might be just marking the desired "frozen" coordinate with e.g. guides and then drag the transform origin there when performing the transformation.
  8. That's how I understood this, too, and can see why this can be a problem in certain situations. Transform point seems to be defined in relation to object's bounding box so it cannot be "frozen".
  9. This is of course the safest way, and certainly recommendable if local formatting is important. But personally I quite often skip this and just rely on local formatting that comes from the original. This also depends on how you import your text. I typically use my own scripts to assign already created paragraph styles to paragraphs that have been tagged with equivalent style names in Word so when the script is run, text formatting is basically done, and I typically use character styles only for stuff like needing to use specific bold type for bold (e.g.. if Ctrl-Shift-B produces Semi-Bold and you want to use Bold), for styling footnote markers, making figures a bit smaller etc. etc. But making regular bold and italics as character styles in the first place allows naturally more control. My point was mainly to note the difference to the way InDesign does this, and possible problems that this might cause. But now that I examined this more closely, I realized that losing the local formatting ONLY happens with default styles, e.g. Body, which is based on "Base" style, which is defined as one crazy negating style that says no to everything possible. If you create your own styles without basing them on any other style, or detach the default "Body" from the "Base" style, you would not lose the local formatting. So understanding this, I think that this works just fine.
  10. I can see how this can be useful if the font does not support all characters of the current keyboard layout (and especially if the keyboard layout deviates significantly from the US/UK keyboard), but the feature sort of backfires in certain situations: As can be seen here, the special keys of Fin/Swe keyboard with åäöÅÄÖ are fully supported in all styles of Noto Sans, yet all fonts belonging to the family are grayed out. This can be considered a bug, and it might well have been fixed in later versions of CorelDRAW. Noto, of course, is kind of a crazy exception as its goal is basically to support all possible scripts.
  11. I think that as for "Apply 'style name' to Paragraphs and Clear Character Styles" command, it actually does "Clear All", but the command name is erroneous as it lets understand that it only affects character formatting that has been done by using Character styles. Its name should be something like "Apply 'style name' to Paragraphs and Clear All", or "Apply 'style name' to Paragraphs and Clear All Character Formatting". In addition, the "Paragraph Style" + "Paragraph Style" marking should be corrected to mere "Paragraph Style" by applying [No style] character formatting to the affected text. As it is now, "Reset" does not have any effect, because the text has already been reset! But I noticed another thing, which is far more serious, and which I consider a major blunder: if text is formatted with paragraph style "X", and contains local formatting, e.g. bold and/or italicized parts, and the text cursor is inserted in it and another paragraph style "Y" is applied, all local formating is lost. This should never happen, and it certainly does not happen in InDesign, which is presumably used as a model when implementing these features. In InDesign, local character formatting is lost in change of paragraph style only if all text of the paragraph is overridden (in which case it is no longer seen as "local"), OR, if the local formatting is deliberately wished to be cleared by using a specific command that forces another style. They way paragraph formatting is implemented now would be a total catastrophe for anyone making a move from InDesign to Affinity Publisher. If e.g. changing paragraph formatting from "Body" to "Footnote" would lose complex and carefully applied local formatting, e.g. italicized book names, person names made deliberately bold, etc., you can easily cause massive non-recoverable damage to the text, resulting in hours of tedious work in re-importing text, or restoring the formatting manually. Have I just misunderstood something, or is this really intended behavior? See attached an .afpub file for different basic formatting situations. Remove_styles.afpub
  12. I think that this is *basically* correct. Adobe apps behave similarly, if configured that way and when *opening" documents (PDF placed in InDesign making an exception) for editing. When you open a document with conflicting profile, you can typically decide BEFORE proceeding, whether the document to be opened will be a) converted to working color space, or if the b) embedded color profile is retained, or if the c) embedded color profile should be discarded (in which case the working space color profile will be assigned to the opened document. Affinity apps handle situation (a) if you have "Convert opened file to working space" checked, situation (b) if you do not have it checked, and situation (c) if you do not have it checked AND double click the placed PDF and choose File > Document Setup and now "Assign" (instead of "Convert") the main document color profile for the document. This can be tested with the K100 PDF document with Coated Fogra 39 profile embedded by doing the following steps: 1) In File > Preferences > Color, uncheck "Convert opened file to working space". 2) Create a new document and ensure that you have other than Coated Fogra 39 as your document color profile. 3) File > Place the PDF with embedded Coated Fogra 39. You can choose Document > Resource Manager to see that the document has "Coated Fogra 39" as the color profile. 4) Double click the placed PDF. Note that you do not get color conversion warning because conversion is not performed. The black has stayed K100. 5) Click File > Document Setup, choose your main document color profile from the list of profiles (e.g. ISO Coated v2 (EFI), or whatever is your main document's color profile), then ensure that Assign is selected. Close the document. If you now choose Document > Resource Manager you should see that the embedded PDF has the same profile as the main document. 6) Export with default (print) settings and confirm that K100 is retained in the produced PDF. If you do NOT perform steps 4 and 5, the document's K100 will be converted at export time to rich black. This assignment procedure is pretty much equivalent to what you would achieve in InDesign simply by "discarding" the embedded color profile at the time the document is imported. But for PDFs this does not apply as InDesign will pass them through anyway and the color values will not be touched (unless you deliberately force this by using non-document profile as your color conversion profile and choosing the option that allows change of color values. (But if you'd open the PDF in Illustrator for editing, regular color management would be applied.) I have tested this with both settings ("Convert opened file to working space" checked or unchecked), and with default Export (print) and Export (PDF-X4) settings, and if you do not manually change rich black back to K100, or change the profile by doing the assignment operation described above, you end up getting rich black in your print PDF. To make the alternative workflow clear, here's a description of what happens if you do have "Convert opened file to working space" checked (I think this is the default?) and place a CMYK PDF with conflicting color profile: 1) In File > Preferences > Color, check "Convert opened file to working space". 2) Create a new document and ensure that you have other than Coated Fogra 39 as your document color profile. 3) File > Place the PDF with embedded Coated Fogra 39. You can choose Document > Resource Manager to see that the document already has your document color profile assigned to it (possibly color values silently already changed). 4) Double click the placed PDF. You get the color conversion warning. Check the text and see that K100 has been changed to CMYK values. (If you now edit the values back to K100 and CMY0, you will have K100 also in export. If you don't, you'll get the displayed CMYK values, whether you opened the embedded file or not.) All in all, color management is not the simplest thing in the world, but the defaults should be such that inadvertent changes from K blacks to CMYK blacks in imported CMYK PDF documents do not easily happen. I can understand that the current situation with PDFs placed in Publisher -- as they cannot be passed through -- is tricky (as the files are basically opened for editing), but as it is, the whole PDF document placement feature (contrary to opening them) would probably do much better if it simply just ignored color management altogether at least for CMYK objects.
  13. You should still be able to run AI and PS as they are 64-bit versions, or??? I cannot see this happen in any near future on Windows. There is far better backward compatibility on that platform, and when the support is finally ended, there will most probably be ways to continue running 32-bit sofware.
  14. That could work only if you have mere black in your PDF (that is, no "color" color), meaning that you'd work with grayscale PNGs, otherwise you're back in square one, having rich black, but this time in RGB mode.
  15. Yes, I agree. The major problem as far as I can see with color management in Affinity apps is that there does not seem to be a way to simply just discard the embedded color profile of imported graphics. You end up in problems like converting K100 (and below) to rich black because of conflicting color profiles, and if you choose to not convert at import time (as per choice done in Preferences > Color), the embedded graphics with deviating color profile will (by default) be converted when you export to print PDF. As it is, it would be far better to be able to import all PDF documents without any kind of color management. Therefore I can see only two “safe” ways to deal with CMYK PDFs with an embedded conflicting color profile and containing K values (non CMY blacks) in an Affinity Publisher document: a) If you do allow conversion in your color profile settings (Preferences > Color > “Convert opened files to document space” is checked), double click the placed PDF document to have it opened on a separate tab, note the warning on color conversion performed by Publisher, and edit the color values of the document (manually forcing mere K values). On the other hand, if you do not allow automatical conversion (and accordinly have the K values intact in the PDF document), double click the placed PDF, choose File > Document Settings for the opened PDF and assign (not convert) the PDF document the color profile of your main document. Now your "embedded" PDF has the document color profile and its K blacks stay as K blacks and will not be converted at export time (as there is no longer profile conflict). b) If it is your hands, do not embed a color profile in a PDF document that already has mere CMYK values. When you do not have a profile, CMYK values of a PDF document are imported as they are. Not actually too practical solutions, as there are still problems with embedded (missing, uninstalled) fonts, and things like overprinting. If I were in a position of needing to place critical PDFs in a Publisher document, I'd simply render them in Photoshop and save them as CMYK TIFF bitmaps with no embedded profile (so you'd need to be careful with color profiles there, too, to not have rich blacks), and then place in a Publisher document.
  16. Their campaigns might be a bit odd and sporadic (e.g., i upgraded from version 2018 as they currently show an offer when you close the app; perhaps they do not show it in context of recently registered apps) but I have upgraded every now and then starting from early versions and do not think that I have ever paid more then 100 euro (or USD) for the upgrade. And older completely legal versions can occasionally be found as kinds of offers Humble Bundle had. I do not think they have a particularly strict upgrade eligibility policy, either, and as they offer both Windows and macOS versions at the same price, there is some benefit for users like myself.
  17. Don't want to arouse false hopes but you might want to check if this holds true (the link below is only to the Painter user forum, not the Humble Bundle site): Stephen 2 hours ago in reply to noriri I have heard that Humble Bundle now has the updated/Catalina compatible installer on their website, might be worth giving the latest a try...let us know if it works! https://painterfactory.com/painter_product_discussion/f/got-a-question-technical-issue-bug-report-for-the-painter-team/30375/cannot-install-painter-2019-on-macos-catalina
  18. I am not sure if the conversion was made in this case when the document was placed or when it was exported. I guess that as Publisher opens rather than embeds a placed PDF, all the color values of the imported graphics are basically similarly treated as colors of the native objects (as that's what they are, more or less), so I'd imagine the other K100 text parts would have been rich blacks, as well. On the other hand, if the placed PDF does have an embedded color profile, and it deviates from the document profile of the Publisher document, the CMYK colors will be converted, K100 becomes rich black (see if you can reproduce this with the attached pdf which has Coated Forgra 39 embedded in an Affinity Publisher document that uses ISO Coated v2 (ECI). This file was produced from InDesign. This is crazy, but correct. Crazy because ISO Coated V2 and Coated Fogra 39 are pretty close to each other, and because there was no point in embedding the color profile in the first place. But ads and pdfs that are supposed to pass through very often do. If the profile is not embedded (which is the default behavior when you export from InDesign), there will be no problems with K100 when you open/place the file in Affinity Publisher. But as it does have, Affinity Publisher behaves as it should, opening a graphics file containing a conflicting color profile, and converting its color values (even if in CMYK color space). I think that InDesign avoids this problem by treating K100 and registration black differently and passing them through, no matter what. Other CMYK values are converted, if dictated by the color management policy (and typically confirmed at import time by the user). Another problem with placing a ready-made pdf (e.g., an ad or a company logo) is that you need to be careful for substituted fonts (as embedded fonts are not supported), and features like overprinting. At this stage, I'd think twice before using Affinity Publisher for jobs that require these kinds of features. 100k_with_embedded_profile_coated_fogra39.pdf EDIT: Forgot to mention the important note that the CMYK color conversion will happen with conflicting color profiles if color conversion is allowed in the Preferences > Color. I am not sure what is the default setting but the point is that even when the warning is applied, it is shown afterwards as a bubble, not as a dialog box that asks the user's confirmation, which would allow discarding the color profile and avoidinf the whole issue. EDIT 2: Tested importing the attachd pdf in Illustrator, and it converts K100 to rich black if conversion is allowed at import time (and not, if the embedded color profile is discarded). InDesign keeps K100 even if the document color space and embedded color space (both CMYK) are conflicting, and even if change of color values is allowed. But the important difference of course is that InDesign passes through the PDF and has not opened it for editing.
  19. Colors are interesting, and complex, and no wonder have inspired many philosophers.
  20. I did not apply the adjustments with much consideration especially as this was a low-resolution version so if something turned blue, some adjustments may have been applied too heavily. But violets of course are not uncommon in this context, either. It helps to have the Info panel visible where you can see color values of different parts of the image. This (especiallly if you have both RGB and CMYK values visible) gives you a good grasp on how to affect each area of the image to bring down are up its hues. I suppose it can be explained by the more broad manipulation of what constitutes "redness" than trying to access directly the red and magenta hues of the image, so in this case Yellows rather thand Reds were manipulated not only by adding both red and yellow components but also by reducing the complementary color cyan, and especially by adding black; in addition saturation of reds was increased, and then on the other hand some counter effect was applied with color balance to tone down redness of leaves on the ground. But I have to say that I basically just played with the controls so what was done was not a result of much analysis. Adjustment layers are great because you do not need to finalize (merge) the manipulations but can evaluate their usefulness and contribution to the total effect, and make further adjustments if needed, or discard them as useless.
  21. You need to tap the red circle first as the saturation (and a slight hue shift) was added only for reds.
  22. Yes, no selections using the selection tool, but when using selective color, of course selective. You could basically use "Yellows", "Reds" and "Greens" alternately to see how you can change the tones in different parts of the image. "Reds" and "Yellows" do affect the leaves on the ground, as well, so if you want to have more red in the uppper part, there might be reason to area select (basically lasso) the part excluding the ground leaves. Levels is more a general tool to adjust shadows, highlights and gamma of the image, so that is not so useful when you need to touch only certain colors. I do not know Photo as well to be able to comment the Live Lighting tool but I suppose these kinds of manipulations are more suitable in bringing up details or for creating special effect rather than tuning the general feel of the image. Often just touching slightly the color balance (especially as that can be done selectively for shadows, midtones and highlights), or adjust the saturation (again, touching only limited hues) is enough. Selective color is a very useful adjustment as you can apply it only to the selected parts of the image, and control the desired hues with all color components (e.g., sometimes it is useful to play with the complementary colors or adjusting neighbouring colors when needing to boost up a specific hue which cannot be accessed otherwise).
  23. The image that I used was taken from your original post so that's why it is pixelated. But if you can open the .aphoto file in iPad, you should see from the Layers panel all image adjustments that have been made to the image. They are "layer adjustments" so they have not been "finalized" so if you tap (double tap?) the icon of the adjustment you can see which kinds parameters have been used for each adjustment, and can easily make similar adjustments to the high-res image you have on your iPad. Note that e.g. for "Selective Color Adjustment" the parameters are not directly shown, as you'd first need to tap "Yellows" to see how the yellow tones have been boosted with magenta. The iPad version of Affinity Photo does not have identical user interface with Windows/macOS version but I suppose it has similar controls.
  24. I am not sure where you're aiming at but you could try by using one or more of the adjustment filters used in the attached Affinity Photo file (primarily selective color and adjustment of saturation), and area selection if you do not want the adjustments to red/yellow to have effect on leaves on the ground. autumnleaves.afphoto
  25. I noticed that having a miter corner join (at least with square caps) causes strokes to be expanded. Using rounded joins keeps them as strokes. Just a workaround, of course, and useable if you do not have corners that lose their desired shape.
×

Important Information

These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.