Jump to content

Lagarto

Members
  • Content count

    672
  • Joined

  • Last visited

Posts posted by Lagarto


  1. This was good to know.

    As @walt.farrell pointed, it seems to be related to styles: .docx based imports include styles and the text will get its K100 definition with the style. RTF text will have [No style] and will be actually in RGB color mode (RGB 0, 0, 0), and would be converted to four-color black at export time if not manually changed. So if the RTF imported text is not formatted with styles that already have K100 as the text color, the first thing to do with the RTF imported text would be select it all and assign it K100 value.

    It is a bit confusing that BlacksGrays palette in Publisher is RGB based so this palette should never be used in CMYK based jobs unless one specifically wants to have rich black tones.


  2. 3 minutes ago, R C-R said:

    Nudge distances are user settable in Preferences > Tools. Defaults are 1 px & 10 px but can be set to whatever you want, including fractional pixel values:

    Good to know about the fractional values but I do not think that this has effect on the "first nudge" issue, as it seems that if your node is initially not pixel-aligned, and you start nudging it, it will move the amount specified by this setting, while it would be desirable that the first nudge after turning on the pixel grid would be done so that the node gets pixel aligned (similarly as it does when moving with the mouse). Thereafter it needs to move 1 pixel at a time to get the nodes perfectly aligned so the nudge setting should be 1px.


  3. 9 hours ago, JimmyJack said:

    HA (I'm laughing with you O.o)! I've got no idea!! see below. I'm not using any modifiers and it's all one click and drag....at the very end I use divide to get one sharp point

    As it is all related to accuracy, I have found one fool-proof way to do this:

    1) Turn off all snapping aids.

    2) If your document is not already pixel-aligned, set it now to align to pixel (but do not force to move by pixel), and then move the start node with the mouse just enough to get it aligned with the pixel grid (do not use nudging, since it seems that if you use nudge, it sill moves 1 px at a time even if you  do not force move by px;; the first nudge does not align with the pixel grid similarly as when moving with the mouse does). Select the end node and do the same to get that, too, aligned with the pixel grid..

    3) Select the end node and use your keyboard arrows to nudge pixel by pixel the end node on top of the start node. Zoom close enough to see that the nodes are aligned.

    4) Select all nodes with the Node tool and click the Divide button. The curve should now be closed, without double nodes and without distortion of the shape.

    I have not found a way to do this with the mouse. With the mouse you get the curve closed without a double node but the shape gets distorted. I have managed to  do this without the shape getting distorted -- similarly as you -- without actually knowing what happened ;-) One time I thought it was holding down one of the modifier keys (Shift, I think), but have not been able to reproduce. 

    But it seems that this really is a question of accuracy. 

    BTW: I am using the release version of Designer.

     


  4. One point worth noting when using a wide-gamut profile as your document RGB profile is that when you export to Web, it seems that Affinity apps by default embed the document color profile in the exported image, which might not be what you want. Adobe apps e.g. typically always use sRGB as the default when creating for web -- no matter what your document RGB color profile is -- as that is the standard and which most devices are likely to even approximately be able to show, and it is a good idea to convert colors to sRGB when producing for web simply to avoid problems related to unmanaged color environment (as you cannot typically control how your files will be handled subsequently). In Affinity apps you'd need to manually change the profile to sRGB to achieve that. 

    Note however that Affinity export settings remember the last used values so if you set this once, you do not need to specify the sRGB profile each time you export using the same export method. But it is good to know this limitation in Affinity apps if you choose to use wide-gamut RGB profiles as your document profile.


  5. 9 hours ago, Toonman said:

    An interesting thing I ran into was that changing my display ICC profile to sRGB instead of Dell's profile, changed the colors displayed in Affinity to the ones shown in the exported image (which made my image in Affinity appear incredibly bright and saturated).

    That's because when using sRGB as your device color profile in system color management, you're practiclly telling the system to map sRGB to use your display's full color capabilities to display a much smaller color gamut. That's totally wrong, and clearly indicated by the fact that you see all your colors wrong in Affinity apps. So you should set it back as it was and stop using your viewer app as a reference point!


  6. On 11/6/2019 at 4:19 AM, Toonman said:

    and also made sure that my ICC color profile in Windows matches what Affinity Photo is using. It hasn't made any difference at all

    Noticed this one thing in your Preferences > Color. You could set this to sRGB or AdobeRGB as the default value. I think these are "just" the defaults that you will get when you do not specify otherwise, but as you do not specify multiple color spaces (RGB and CMYK) per document in Affinity apps, as you do when you create an Adobe document, these settings can be used silently in operations not clearly defined, and it is best to use here sRGB or Adobe RGB rather than your ICC color profile, especially as it is not based on measured results.


  7. When you work with a wide-gamut display (your display can show full Adobe RGB color space and some plus), it is important to have a hardware calibrated device color profile. The factory default is not necessarily working well as it depends on your monitor contrast and brightness settings being at correct values to give the assumed luminance for which the profile is defined,  

    But let us assume that the your Dell device profile works well (and it most probably works better than anything else that you can use as the monitor profile), and you use that profile with your system color management so that whatever profiles you use in different apps and receive embedded in documents, gets mapped via this device color profile. 

    When you create your documents in Affinity apps, you could well use your device color profile as the RGB color profile of your document, to have the full gamut of the monitor, but then you should always use file formats that support color profiles and embed them in the files you produce so that colors get mapped to profiles that users who receive the files and watch them on different kinds of devices get the colors mapped correctly,

    If the file does not have an embedded profile, or if the viewing app does not support color profiles you can get varied color outputs from different sources.

    What typically happens then?

    1) If you (having a wide-gamut monitor) get a pure red image (RGB 255, 0, 0) without a profile, and your app does not assign the file some default profile (like Adobe RGB, sRGB, etc.), and you choose to view the file using your device color profile, you would get screaming red on your screen, far more red than someone watching the same image on a standard display (many of which rarely even can show full sRGB color gamut), so it is clear that you would get all colors wrong, as not intended.

    2) If you (having a wide-gamut monitor) choose to create your document using your device RGB profile, and fail to embed the color profile, the receiver (typically not having a wide-gamut monitor) would get a bit dull colors, as you would most often use subdued color values, to avoid overly saturated images. If the device color profile is embedded the colors would be mapped on receivers displays so that the general feel is the same as on your end.

    3) If you create your documents using different RGB color spaces (mixing e.g. your device color profile, Adobe RGB and sRGB), and fail to use embedded profiles (to get colors mapped for your wide-gamut display), you'll get inconsistent colors from session to session.which can have negative effect on the quality of your work.

    4) If the viewing app does not support properly embedded color profiles or cannot use system color profile (based on color managed and measure devices), it may show wildly varied outputs, and typically shows overly saturated colors on a wide-gamut monitor -- no matter what color profile is embedded in the document.

    Other impiications on using a wide-gamut display:

    If you create your documents using your device color profile as the document color profile, and also embed that profile in your documents, the receivers may get different results depending on what kinds of displays they have: if you have used some colors using full gamut of your display (e.g. certain PMS colors like orange), only receivers having a display with equal capability, can see the colors correctly; most users see below sRGB colors so whatever colors exist beyond sRGB will be mapped within those limits. This is not a problem, as this is basically what happens all the time when you e.g. produce anything in RGB color space and convert it to CMYK to be sent for printing. Because color profiles are used, the colors get correctly mapped from device to device.

    ========

    The safest choice is naturally to choose sRGB as the RGB color profile and some standard print profile for coated paper as the CMYK color profile, since these are the most common outputs for web and prints. Many designers use Adobe RGB, instead, because professional cameras use that color space, and some use ultra wide gamut color space profiles to be able to display all PMS colors or working with 16-bit color modes reliably. There is no problem since either these profiles would be included in documents that are output and get delivered for different purposes (for web, to printer, etc.) along with information about the target color profile, or the colors would be converted at production time for narrower color gamuts, e.g., from Adobe RGB to sRGB when creating for web, or RGB to CMYK when producing for print.

    When color management works properly and color profiles are included in documents, it is much the same what profiles are involved in the process. E.g., if you choose to create your documents in sRGB color space, and you import there three files each containing a rectangle with color value RGB 255, 0, 0, and first of the files contains your own display color profile, the second one an Adobe RGB profile and third one an sRGB color profile, all these reds would be mapped to sRGB 255, 0, 0 (the max that your current profile allows), which means that you would not see any of those screaming reds that your display can physically output. Or conversely, if you create your document using your device color profile, you'd see one screaming red, one fairly saturated Adobe RGB red, and one sRGB red .

    ========

    So why have you experienced overly saturated colors?

    I downloaded your viewer app, XnView MP,  installed it on Windows 10 Pro, created a file using the red of your document, and RGB 255, 0, 0, and viewed the files side by side using Affinity Photo and XnView MP viewer on a ultra-wide-gamut display. The results are in the attached TIFF files with my device color profile embedded so they are descriptive only if the viewer has an equivalent or at least a wide-gamut display. The reason for your problems is that XnView is not much of a viewer. It shows your AffinityPhoto created sRGB documents overly saturated, just like you mentioned, but cannot on the other hand show the full gamut of the display either, when showing an image that has a device-color profile embedded.

    So my advice is: use definitely your Dell device color profile with your system color management (in lack of anything better), and preferrably purchase a basic hardware calibrator like X-Rite i1Display Studio to get measured color values and luminance. Wide-gamut displays do not usually work well with standard ICC profiles and software calibration (which is not calibration at all but just basic settings without measurements). And stop using XnView as your output checker!

    There is nothing wrong in your Affinity Photo document. But the PNG file, when opened in Photoshop CS6 gives a warning about the file format used not supporting embedded color profiles, which seems to be Adobe style of telling that the image does not contain a color profile at all (I think I get similar warnings if I export to PNG from Affinity apps without embedding a profile; Affinity Photo does not give any warning of these files and silently just assigns them an sRGB profile). How did you export this file? Anyway there is no oversaturation in your PNG file.

    srgbprofile.tif

    devicecolorprofile.tif

     

     


  8. 57 minutes ago, JimmyJack said:

    somehow the behavior changed. Not really sure what I did. But I think that part is ok now.

    How did you resolve this? I have now tested with these kinds of curves where the closing point is sharp and I really struggle with them, and do not seem to be able to close the curves without double nodes or distortion (when merging manually).Divide has not helped me with this, at all.


  9. 1 hour ago, JimmyJack said:

    Still doesn't address @thomasbricker & @Lagartos' original question about joining the two end points of a single curve while maintaining curve fidelity without double nodes.

    The method shown by @haakoo does, at least for all test cases I have run so far. E.g., create a circle, convert it to curves, break it from one node; then select all nodes and click Layer > Geometry > Divide. The path is closed without overlapping double nodes and without distorting the shape.


  10. I had yet another look on the issues related to joining the nodes and it is more complex than I thought.

    It seems to be all related to accuracy. I initially assumed that joining (fully or nearly) overlapping nodes -- including multiple nodes -- is a straight forward operation in Illustrator, but it actually depends on accuracy.

    E.g., if the MergingNodes file provided by @Tazintosh is exported as an EPS file and opened in Illustrator, it really can be merged into one curve without generating double nodes in one go, selecting the paths and pressing Ctrl + J (for Path > Join), as the nodes are then considered to be overlapping (endpoints exactly aligned to each other). But if it is exported as an SVG file (from Designer), the same operation would create double nodes in Illustrator, exactly as in Designer.

    Illustrator however provides good tools to force the merging: Shift+Ctrl+Alt+J (Average & Join) joins two closely adjacent nodes ("anchor points" in Illustrator terms), and you can also use a script to do this for multiple selected (nearly) overlapping nodes in one go, using a customizable parameter as a tolerance value (max distance of adjacent nodes to perform merging). And when merging nodes manually, Illustrator snaps to anchor points better than Designer, and also shows the text ("Anchor") when the anchor points meet.

    CorelDRAW behaves much as Illustrator, as merging multiple overlapping anchor points can be done only by using a macro that accepts max distance as a parameter. Nodes near to each other, however, can be merged by just selecting them and clicking "Join two nodes", and manual merging of nodes happens easily especially when snapping to objects is turned on.

    Inkscape is the only one of these apps that can do merging of selected multiple (fully or nearly) overlapping nodes in one go in the user interface (clicking a button on the toolbar or pressing Shift + J) -- I do not know if the tolerance for merging can be specified with a user-defined setting.

    The more serious issue related to merging of nodes -- problems in Designer to close a curve without double nodes or distorting the shape of the curve -- is not a problem in other apps, and thanks to method shown by @haakoo does not seem to be a problem in Designer, either. I had not realized that Divide boolean operator could be used this way.

     


  11. Thanks, that was clever!

    I just did it third time by manual joining and found that if nodes do not "snap" at first, it helps if you first move the start node of the next segment and undo the move, and after this drag the end node of the previous segment on top of the start node of the next segment. For some reason snapping then usually happens and you can perform node merging without generation of double nodes.


  12. 7 minutes ago, Tazintosh said:

    You nailed it!!! Could you please describe your process?

    Yes, please share! I can join the nodes about 50% of the time by zooming in really close and dragging the end node of the preceding segment right on top of the start node of the next segment until the segment is highlighted. Then, using the Shift key, both segements are selected in order preceding and following segment, and Join curves button is clicked.

    The problem is that sometimes when dragging the nodes do not "snap" (no highlighting) so I may need to first make a merge where double nodes are created, then break the curve, and make another attempt.

    I have not found that snapping tools are useful here.

    Hopefully there is some trick that makes this easier. I still keep on creating lots of double nodes but that seems to depend also on the kind of segments that need to be joined.


  13. 1 hour ago, Nieck said:

    I have 787 active fonts at the moment and use Font Explorer XPro version 6.0.3

    Use of font manager could explain it. 

    But as I now tested this on macOS Mojave, just using Font Book, it seems it can be app dependent how fonts are handled. E.g., simple apps like Text Edit handle system font notifications immediately, but Pages only processed font installation notifications, but kept the font resource in memory during the current session, even if the font was removed, meaning that it probably would not refresh the resources for that specific font if an updated version of it were installed.

    Affinity apps might behave similarly, which would of course be a nuisance in point of view of font development, as you'd need to constanly close and open the app. I do not currently have Affinity apps installed on macOS so I cannot directly test it, so this COULD also be Font Explorer XPro related, if it has app specific operations and Affinity apps are not directly supported.


  14. 33 minutes ago, R C-R said:

    To be fair about it, the Inkscape example uses constant width curves (no stroke pressure variation) unlike the MergingNodes.

    That is completely irrelevant as regards the task, and topic of the thread (which in addition to closing the curves, deals with problems with joining the nodes in general). If you want to have the pressure curve applied to the Inkscape created joined curve, you can simply copy paste it in Designer and apply the style and desired stroke width.

    I guess a pressure curve was initially applied just to make the point. The shape shows clearly what happens when nodes are truly joined / merged in one. If a double node is created instead of a merged one, you can easily see it because of rendering (there will be a streak between the stroke segments, showing the miniature misalignment of the two nodes).


  15. See attached Publisher document.

    1) Select the gray transparent rectangle (it has K100 applied, and layer opacity of 55%).

    2) Select the Color Picker tool from the toolbox.

    3) Click on the selected gray rectangle. Its color assingment changed to K55, while transparency setting is retained as 55%, accordingly the vsiual outlook of the object being changed.

    Can this be intended behavior? The feature picks now the color of a transparent object against the background (at the point where color picker is clicked), which in this case is K55, as the layer transparency of 55% combined with the fill color K100 produces K55, but then applies the color to the object itself without removing its transparency.

    If this feature is intended to mimick the Eye Dropper tool of InDesign, it does not behave like this. It applies the selected object e.g. the color assignment of the fill, AND if the object has an opacity setting, it will be copied as an opacity attribute to the selected object, as well.

    eyedropper.afpub


  16. 26 minutes ago, Wilfred Hildonen said:

    Yes, I have seen that, but this isn't a trace feature. It is a simple conversion from greyscale to lineart.

    No, this is unfortunately not supported. You could use GIMP to do this, but this is yet another good reason to keep Photoshop CS6 installed forever. Note that Affinity apps do not support bitmap images (1-bit monochrome) at all, so if you open or place one, it will be converted to RGB.


  17. 14 minutes ago, R C-R said:

    @Tazintosh asked about easily merging the curves, & that is literally what Layer > Geometry > Merge Curves does.

    That's a terminological problem. Different apps call same operations with different terms. But it was obvious that OP meant merging the nodes, not just combining the separate curves as a compound object. In CorelDRAW and Inkscape this kind of "merging" (where the nodes will not be joined or merged) is called "combining", and in Illustator it is called creating a "compound path".

    See from post by @Pšenda (containing the accomplished task as an attachment) what was meant. The intention is shown also in the filename. 


  18. This is the stuff that gets overlayed as a bitmap on top of the drawing:

    overlay.jpg.527d77be15866cad552586e62e3f8267.jpg

    I'd try to isolate something that is immediately above the elements of this image, especially those yellow lines on top of the building. One of these lines might have an effect that causes rendering on everything below as a bitmap.

    I opened your pdf in Illustrator, extracted the rasterized layer and removed the white background from it and then replaced it with the manipulated version. I then opened the saved Adobe Illustrator file in Affinity Designer and created a screen pdf, see below. If you wish to have the edited Designer file, and do not mind it being available publicly here, I can place it on the forum (its size is 5.8MB). This way you could replace the bitmap with a high-resolution version, or try to replace the bitmap with the real objects, seeing that they do not cause the same problem again.

    It would  be really educational to know what exactly causes this problem. Personally I think that the Affinity layer model is prone to these kinds of problems (though it is of course a matter of learning to work and organize stuff in a bit differrent way than you're used to in Adobe apps). These kinds of problems can be hard to detect or isolate afterwards because you cannot see the effect of an individual adjustment at render level in workspace, so you only see the error after having created a PDF. Therefore t is a good practice to create print-quality PDFs quite often to see that there are no problems.

    DRAPER Project_Lookout component_PLAN view (without GRID) Best current_screen.pdf


  19. 15 hours ago, Nieck said:

    but I need my original testdocument to work in

    Do you mean that the font does not ever get updated or appear in full resolution in the original document (even after you have created a new document with an updated font operating fine there)? Doesn't it update even if you type in some new text using the font in the same document? I'd try "save as" (saving under the same filename) to see if that could purge any old stuff stored in the file.

    5 hours ago, R C-R said:

    font changes are updated in realtime in the Mac versions, although I am not certain of that

    Font cache does get updated "real-time" also on Windows, but in Affinity apps not in Windows way (even Notepad gets updated in a couple of seconds), but within a minute or so (depending on the number of fonts installed), probably because Affinity apps enumerate font menus from the scratch rather than simply refreshing them.

×

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.