Jump to content

Lagarto

Members
  • Content count

    650
  • Joined

  • Last visited

Everything posted by Lagarto

  1. Lagarto

    Default Color Values

    Do you get the CMYK readings for the swatches 1 and 2 from all controls (Color Chooser, Color (with CMYK sliders), and when adding the color from an object that has been colored with these swatches in the document palette (see my original screen shot where I have added black and gray swatches in the document palette)?
  2. Lagarto

    Default Color Values

    So the lock does not have anything to do with this. No clue how these basic swatches can change if the document color space is CMYK.
  3. Lagarto

    Default Color Values

    Odd. There seems to be some setting that causes them to change. I cannot myself reproduce this so even after having chosen Black or Back 50% from the Grays palette, I still get K100 and K50 if I click on the wells 1 and 2 There is a lock on the Color palette beside the color model selector the operation of which I have never understood. I think that by default it is turned on. Do you have it turned on? (It probably does not have any effect on this issue, just random guessing...) Is this something that has changed recently (so that you have previously got K50 and K100 values when using these wells)?
  4. Lagarto

    Default Color Values

    I can get those values if I click on the Black and Black 50% wells in the "Grays" list, but these are actually RGB based colors, similarrly as all color wells in the Colors list. But if you click the standard black and gray wells on the right of the Swatches list (the ones that you have marked with numbers 1 and 2 in your original post), you should get K50 and K100 always if you have a CMYK document color space. This is a bit confusing as most other apps use separate palettes and standard libraries based on document basic color space.
  5. One obvious reason would be having the preview mode on... Does the spelling check feature itself work (Text > Spelling > Check spelling) even if the red wavy lines do not show? Does hyphenation work? (Just to make sure that there is no problem with installation...)
  6. Lagarto

    Default Color Values

    How did you get those readings? As can be seen in the screenshot, all color controls show K100 (and K50) for the two objects created in a newly created CMYK document. The colors have been asiigned by using the standard black and gray wells of the Swatches panel. Is this something that you can reproduce consistently?
  7. That may well be true, so it may be useful to show that equivalent things have been implemented in apps that are intended for similar audiences. If there are many users, there is definitely need for specific features even if only small percentage of users need them on a daily basis. And many features can actually be quite easy to implement There was recently another post where length of curve was asked as a feature and the first replies were in the line that these kinds of features only exist in CAD oriented software, etc., and are rarely needed in graphic design. But it turned out that you get this information in Illustrator, Inkscape and CorelDRAW, and that the feature can be very useful in practical applications for users that do not need power of CAD, e.g. for determining price for laser cutting jobs.
  8. Lagarto

    Default Color Values

    They should be, if you created your document as a CMYK document. But the CMYK equivalents would be something like mentioned in your post, if the document color space is RGB.
  9. After having spent quite a time with this feature, I must say that I cannot answer to the question of this post. There are situations where the command seems to operate similarly as InDesign's "Apply Paragraph Style, Clear All", and other situations where the only way to get rid of the local overrides is doing manual formatting. In InDesign and QuarkXPress local formatting is something that is not easily lost accidentally (e.g., it does not happen when you change the paragraph style), not even in situations when there is no equivalent styling in changed conditions (e.g., the font of the new style does not have italic style, but instead oblique). On the other hand, when deviating styles are wanted to be cleared, it is straight forward to reset all local overrides and character style based formatting, either separately, or both at the same time.
  10. One aspect here is also what happens when you find and replce with styles? I do not think that there are options for preserving local formatting, or all those special cases that exist in context menus, when doing find/replace so if finding and replacing with styles means that local formatting can potentially be lost in the process (that is, if it behaves simiilarly as when performed by command, local formatting sometimes being lost and other times retained, on grounds that are not obvious), then it is better to never use the feature for paragraph styling. EDIT: That is, unless your local styles are first anchored with character styles...
  11. Related, yes, though in this post asymmetric corner handling was asked. These kinds of options would be very welcome!
  12. I think you've got a point. Probably poor UI rather than actual bugs. in test 1 I cannot see the point of the upmost box being editable. It does not seem to find the next occurrence of the user-specified mispelled word as a search operation (in a situation where the specified misspelled word actually exists in the text). Basically the box just shows the next misspelled word always in the order determined by the spelling check function. It won't show "cat" because that's en English word and not marked as misspelled. The box could well be read-only. (UPDATE: Cannot, because that's where the replacing word is typed, too; there is no separate Change to box, which also means that each occurrence of the same error needs to be manually typed over and over again.) In test 2 it would certainly be more intuitive if the list would be updated as the found entries are replaced. This way you can also see which occurrences were not replaced and return to them if necessary. Once the found entry is replaced the point in text can also no longer be brought in focus so it is basically useless to show them in the list of found occurrences any longer (in the form of searched text; if the text were updated, there would be point, and the text point could then possibly be brougt back in focus, as well)..Or perhaps there is some logic I just fail to see.
  13. A Ahh, sorry, should have read more carefully. It did not seem that the post was considered an actual bug but this is really quite disturbing as the shadow mask should not have any effect on layers below and should be restricted to the ruler image. I have noticed that some odd rasterization errors can also be corrected by using the pdf export setting that disallows rasterization on "unsupported" features. E.g., there was a post where imported group of curves was rasterized because the group had "passthrough" blend setting that actually did nothing. Setting the blend mode to "Normal" or using the disallow rasterization setting produced then an expected pdf. They do many things cleverly and run well even on pretty low-level tablets like my old Surface Pro 4 (with only m3 processor and 4GB memory), and work nicely with a pen, so I'd say there is much promise. So far I have used them mainly for digital-only projects; for print jobs one needs to pay some extra attention but it is workable. They are at v1.x stage and it naturally shows.
  14. I had a closer look on the pdf I produced from the .afpub document attached in the post, and noticed that the use of shadow in the rulers seems to have caused for some odd reason the whole top part, also the logo, to be duplicated. Below I have offset the shadow part. While the bold appearance was partly caused by the viewer's smoothing setting (as the duplicate text is actually rasterized and not in text format), this seems to be a genuine bug in Publisher's PDF creation routine. I tested this also with print settings and it happens there, too. The duplicate problem would have shown much more clearly when using screen pdf settings where the rasterized text would have shown even without the smoothing setting having been used.
  15. This is a safe choice if you want to guarantee good readability or avoid issues like in this post, but sometimes you want to have e.g. blend effect where image needs to be on top, or play with transparencies in a way where text is wanted to barely shine through, etc., so basically it is the aesthetics that should count, especially if you can ensure e.g. from a ripped proof that this does not cause problems in print. And it is of course good if these kinds of problems (even when caused by customizable enhancements in a specific viewer) can be avoided with some simple change in code that creates the pdf, as long as it does not involve change of z-order of objects or anything that could have visual effect on the work itself.
  16. I wonder if this could actually be the known "problem" with Adobe Acrobat, or have you used other PDF viewers, as well? If you have transparencies on the page, and you use "Smooth Images" setting (File > Preferences > Page Display in Acrobat Pro 10), which I think is by default turned on, the transparency causes the underlying text to appear as bold. This should not appear in print, but is of course a nuisance if the pdf is intended to be watched on screen. However other viewers that I tested (Chrome/Vivaldi, Edge and Firefox plugins, Debenu PDF Tools Pro, PDF X-Change) do not have this issue, so it could be seen as an Adobe feature, and it can be avoided by placing the text at top so there is point using this trick at least with screen pdfs. Actually similar problem occasionally happens also in InDesign (when editing) when using drop shadows and transparencies, but I do not remember the exact factors that trigger it (perhaps using both effects on the same object): the neighbouring/underlying text will render poorly and looks as if it were in bold when looked at distance. a) Image smoothing on: b) Image smoothing off:
  17. If you stil have the print pdf of the book cover and open it in Photoshop, do you get the same values? If you do, I'd say the printer has made a mistake. One possible explanation may be that the deep black in the cover may have contained too much tint for their process and they have run a routine that reduces tint. In that process, the grays have changed, as well, but in a way that has caused cyan to become too prominent.
  18. Certainly not. Did you get this with the mentioned CMYK values?
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  25. 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".
×

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.