Jump to content
You must now use your email address to sign in [click for more info] ×

thomaso

Members
  • Posts

    11,643
  • Joined

  • Last visited

Posts posted by thomaso

  1. 14 minutes ago, Gianni Becattini said:

    The problem was near to the page where first I thought I found the problem and, in all this work, I could separate a small file that crashes also on M2.

    So your first 'culprit' (7A13) was not involved at all but just seemed to be for 1 hour?

    Good luck with the new suspect! – Can you upload this if it continues to be the culprit for quite a few hours of successful work in the affected .afpub?

    Just curious: why did you choose GIF as the replacing file type? (not PNG or JPG or even PDF for instance)

  2. 2 hours ago, Gianni Becattini said:

    I found a reason for the problem. It seems to be in a AP file, included by the APub document.

    1 hour ago, Gianni Becattini said:

    Ignore my previous message. After an hour it started again as before....

    Was the AP document linked or embedded?
    Are there more instances of that Affinity document placed within the affected APub document … or any other Affinity document?
    Can you open their originals (not their instances in APub layout)?

    Do the placed documents use font files that aren't identical on the two computers?
    Can you exclude a font issue / corrupted font file?

  3. Hi @wtbusiness, Welcome to the Affinity Forums!

    None of the 3 Affinity apps offers the creation of HTML & CSS for web sites which appears to be required for a flexible layout, displayed with variable font size and column width for instance. Web sites use "responsive design" to take into account the user's device + screen size + screen orientation when displaying content.

    If you want to publish the newsletter as PDF or PNG for instance AND get the layout & font size auto-adjusted on the various devices you might use/need a workaround by creating several layout versions, e.g. one for mobile (portrait format, larger fonts), one for desktop (landscape, smaller fonts) and ideally even a third version for tablets, each layout with suitable font sizes … and make the web site code decide to deliver the appropriate version to a specific device and user.

    Although you may create several versions of a basic layout with the support of APub's "Constraints" panel for multiple sizes and page orientation you would still need to export each version individually with its fixed size, aspect ratio and orientation.

    If you only create + publish one layout version, you will have to choose a compromise with a layout + sizes somewhere between the possible screen resolutions / sizes that either results in an optimal display for one device but is less useful for other devices, or in a layout and font size that may appear too large/too small on any device.

  4. There might be a workaround for AD. (in APub it would be easy with Data Merge).

    1. I'm using a vertically long document that can hold multiple vertical copies of the image.

    2. Then I create one long text frame which contains the various text paragraphs with the leading set to the image height. (If each text has more than 1 line you need to use "Space after" additionally with reduced leading to achieve the image height as sum.)

    3. The text frame gets nested inside the image layer. With "Lock Children" activated a duplicate of the image+text gets moved by the image height. Then with "Power Duplicate" the multiple copies should be easy.

    4. In the Export Persona all copied image layers get selected + turned into slices with 1 click for export of all image copies with 1 click.

    Unfortunately I run into an issue: it seems with Power Duplicate (cmd-J) the active layer attribute "Lock Children" gets ignored. This feels like a bug to me – but possibly it got fixed in V2? (this not locking children also occurs when using multiple power-duplicated copies of Artboards, one for each image+text).

  5. 3 hours ago, AvdB-Netherlands said:

    Maar wat is nu een "mooie standaard" instelling?

    As usual "beauty" is a matter of taste. For text justification it concerns the balance of black & white (text, ink <-> blank, paper, gaps, spaces). Concerning "justification" it refers to the look of  line end/start in left/right aligned text and to gaps in justified text. For justified text and apart from hyphenation it mainly focuses on "rivers" that may prevent a balanced gray (black vs. white). To detect those areas it helps to zoom out or look at the layout from a larger distance.

    It gets influenced by hyphenation settings + word / character space settings. The latter gets mainly set as Paragraph Style attribute (but may also get set as Character Style attribute, in particular for more individual adjustments, especially in short text or line length/column width). Affinity starts with a useful default spacing: Characters: 0% | Words: 80% / 100% / 133%.

    There are many web articles about these aspects, for instance:

    Bildschirmfoto2024-04-25um11_51_58.thumb.jpg.f8c0c37b2e4ca161418de7553d8bf1b4.jpg

    Bildschirmfoto2024-04-25um11_52_20.jpg.6d6524ae4cc7005f6b233b07122c733f.jpg Bildschirmfoto2024-04-25um11_52.20Kopie.jpg.7581c8f546a0d33c650f5c7fa6969649.jpg

  6. 11 hours ago, lacerto said:

    good workaround

    … whereas the issue appears more problematic than usual issues because this doesn't get obvious neither in .afpub nor in an exported PDF. (… unless the user checks the TAC as you did in your video, which should not be necessary after assigning a profile to the document or for PDF export, especially for PDF/X).

    Do you know if this was ever (bug-)reported for V2 ? (… I never have noticed an according bug report for V1 and I have V1 only).

  7. 1 hour ago, lacerto said:

    Note how Affinity apps appear to require refreshing of placed RGB images before ink limit of a changed profile takes effect (something that does not happen when using e.g. InDesign, so there both early and export-time profile reassignments are correctly applied for RGB objects when exporting to PDF) -- I have a feeling that this did not happen earlier within Affinity apps, either. It also seems that the macOS versions are even more broken as there (at least with native chip on macOS Sonoma 14.2.1 and latest Publisher 2.4.2) assigning a different CMYK profile does not seem to have effect on conversion of neither native art in RGB color mode (the RGB 0, 0, 0 black rectangle), nor in RGB image, so on macOS profile-based TAC limiting is badly broken.

    What a nasty issue. It also occurs to me in APub V1. After assigning the other document profile then switching the colour model in the Colours Panel does not refresh the image and TAC values (but applies a fill colour, even if the wells are set to none before). Instead I can either replace the image (which is not useful) or save + close + reopen the document to get the profile with correct colour values / TAC displayed. Without this additional workaround also an export shows the values of the former document profile (when placing the image) though PDF/X-1 is using the correct intent for export.

  8. 43 minutes ago, R C-R said:

    No, it just means that something in a thread running in the benchmark test that was using hardware acceleration caused a thread crash, but that by itself does not mean hardware acceleration is unusable. This is because there could be other causes that if identified & eliminated could make it usable. I mentioned several examples of fixable causes above.

    28 minutes ago, R C-R said:

    If nothing else, imagine how users would react if the crash was caused by an incompatible add-on & they later learned that by simply either removing it or making an exception for AP if it provides for that, then they could use hardware acceleration. Same for a damaged or missing file (in either the app or the OS) that could be replaced with a good copy.

    The current workflow for such issues asks users to change their current hardware acceleration setting to see if an issue they are experiencing still occurs. If this helps prevent the problem, the situation is considered resolved – regardless of a possible alternative culprit or solution. The mentioned self-test routine might work similarly with the corresponding conclusions.

    As Walt says, it doesn't seem useful or necessary to discuss any further details in the forum – nor is there any need to convince you.

  9. 1 hour ago, jweitzel said:

    Are there any opinions on the performance of OpenGL versus Metall?

    If you have APhoto you could try the "Benchmark" feature to get an impression for your specific hard-/software configuration. Run it twice, 1x with Metal, 1x with OpenGL activated.

    https://affinity.help/photo2/English.lproj/index.html?page=pages/Extras/benchmark.html&title=Benchmark

     

  10. 3 hours ago, walt.farrell said:
    5 hours ago, thomaso said:

    It appears that Affinity doesn't fully support "Hardware Acceleration" of various computers and/or operating systems, right? (…)

    I don't think that's quite right, at least for Windows.

    I can't follow your conclusion. The fact that faulty GPU driver software causes issues does not affect the question whether Affinity is fully compatible with Hardware Acceleration in general. If Affinity would be fully compatible then all these issues were caused by faulty OS or drivers but not by Affinity – which appears odd if you consider that apps and documents are coded for specifications given by the OS, not vice versa.

    For Windows it appears additionally confusing that Hardware Acceleration is an Affinity System Requirements although + while this feature in particular may need to get disabled by users in case of lacking compatibility.

     

    3 hours ago, walt.farrell said:

    I'm not sure to what extent that would be possible. If the error is one related to the on-screen display, such a test would require that the application be able to contain a copy of the expected screen display given a particular starting point and sequence of applications, and that it then be able to perform those operations and then retrieve, from the GPU, the current screen display to make a comparison. If that that retrieval is possible, then what you propose sounds like an interesting idea. 

    True, a feedback of screen rendering versus display might be required to control the reliability of both input + output. I assume such an interface exists already in particular for GPU or monitor development.

    But hardware acceleration not only causes rendering/display issues, but can also cause Affinity to freeze or crash, according to related posts.

    Could Serif use their existing "Benchmark" test code, perhaps augmented with display feedback, to provide a reliable recommendation for an "optimal" performance setting for any specific, individual hardware/software configuration?

  11. 35 minutes ago, caroline daniell said:

    I must have had V1 if I had these styles. But then I upgraded to V2 as recommended & have no idea what's happened to V1.   How do I find it - I must have it somewhere?

    The V1 preference files might still exist in your system folder. (The location depends on your operating system + its version + the used Affinity store for app purchase/installation).

    If you did not delete the related V1 folder then this two posts might help to get wanted V1 content transferred to V2:

  12. On 4/20/2024 at 5:59 PM, MikeTO said:

    Turning on hardware acceleration will not slow down Affinity, it should only speed things up. If you're having stability issues then turn it off.

    Sorry for my imprecise "slow down" (to me an issue caused by activated acceleration results in a 'slow down').

    My question rather concerns the general handling of this performance setting: It appears that Affinity doesn't fully support "Hardware Acceleration" of various computers and/or operating systems, right? So I wonder if the app would be able to selft-test its compatibility on a specific configuration with the goal to choose the 'optimal' (most compatible) setting automatically … instead of a need for "trial & error" executed by users and/or "guessing" by Serif moderators, as in this current/recent thread for instance:

    Accordingly, I would like to understand whether a particular setup (= hardware + operating system + Affinity version) causes the same/identical results (in terms of compatibility + possible issues) across all identical setups or whether its compatibility may vary even in these cases and if yes, what else does it depend on?

    While it is known that the compatibility also depends on certain tasks executed by/in Affinity it is not useful or possible to activate/deactivate the according performance setting for certain tasks selectively, especially since changes require an app relaunch, right? Thus it appears useful & required to make a general decision for a specific hard-/software combination.

    With other words I wonder why it happens at all that Serif/Affinity appears not to know what setup (= hardware + operating system + Affinity version) will cause issues and which will be fully compatible? Of cause Serif can't test all possible configurations but it appears odd that this topic still occurs even though "Hardware Acceleration" is used on various hardware & operating systems since years (i.e. on Apple years before the switch from Intel to Silicon chips) – but wouldn't each of the existing reports complete a possible list / table of compatibility to reduce the need of "trial & error" done by users / Serif moderators?

    Wouldn't a table like this shed light on general compatibility of hardware acceleration & certain Affinity tasks and enable Serif developers to a prediction about (im-)possible compatibility? https://developer.apple.com/metal/Metal-Feature-Set-Tables.pdf

  13. 25 minutes ago, Colin Hartridge said:

    I was thinking of the line around a text box as in the included file. How do I remove the lines around the text?

    While there is no way to hide this selection box for the app in general, you might activate the option "Hide Selection while Dragging". If pressed, it affects all types of objects, not an object individually.

    Bildschirmfoto2024-04-23um10_17_14.jpg.cda2f846cff142adff2cd76b881a82ad.jpg

    To hide the bounding box of unselected objects (e.g. the Picture Frame in your screenshot) you can activate the option "Toggle Preview Mode".

    Bildschirmfoto2024-04-23um10_25_25.jpg.6ad473bd3c32350c1b1d8ec1a305c08d.jpg

    To hide the bounding box of unselected Text Frames there is also the menu option "Show Text Flow" which affects text frames whether they are linked to others or not.

    Bildschirmfoto2024-04-23um10_36_37.jpg.53286b0074c824d408e8f6af0b1e44ff.jpg

    And for Text Frames there is also the menu option "Show Special Character" to toggle their visibility regardless of "Show Text Flow":

    Bildschirmfoto2024-04-23um10_43_13.jpg.d0180a7ce7d4e8b8d09fc523cb642455.jpg

  14. 8 hours ago, PeteBoi said:

    Affinity Photo 2 and need to toggle marching ants off and on, (note: not deselect). I've looked at the previous posts on this and it doesn't seem to have been resolved. Can this really be true?

    Apparently not true: It was already resolved/answered in the first reply of this thread:

    On 2/15/2017 at 11:45 AM, MEB said:

    Go to menu View and untick Show Pixel Selection. You can also set a custom shortcut for this in Affinity Preferences, Keyboard Shortcuts section (set the first dropdown to Photo and the second to View).

  15. 18 minutes ago, Oufti said:

    I find this very handy… 

    Its 'handyness' may vary with the spread aspect ratio (+ document/screen resolution) because it zooms to the centre if it gets used in the full spread view (i.e. after double-click in the Pages Panel or CMD-0) which zooms to the spine on 2-page spreads. Unfortunately even having a layout object selected does not ensure a 100%-zoom reliable to this specific page area, neither with trackpad double-tap nor with keyboard shortcut CMD-1. (unlike zooming via the scroll wheel, which takes the cursor position into account quite well)

  16. Vor 4 Stunden sagte AvdB-Netherlands:

    Nog eenmaal: Anchor to page of Anchor to spread.

    To avoid possible confusion with your recent thread: This "Anchor" setting is not relevant when defining page/spread Margins nor for PDF export but only when you change page or spread dimensions in your layout document with the anchor as fixed position of scaled objects relative to their (single) pages or (2-page) spreads.

    The  Help says:

    >> Scaling (both dialogs, any scope):

    • Position—when changing page size, you can anchor the existing page content to the page or spread (they remain the same size) or rescale it in relation to the new page size.
    • Anchor—sets the anchor point to which existing page content will be anchored to upon page resize. <<
  17. 5 hours ago, NathanC said:

    normally results in a performance boost.

     

    Quote

     

    Benefits

    In practice, the performance boost depends on the task at hand.

     

    Does this mean that Hardware Acceleration in some situations improves the Affinity processes while it slows down the performance for other tasks and thus there is no 'optimal' setting for a general app usage on a certain hard-/software configuration?

    I wonder because the app "Topaz Giga Pixel" offers in its app preference an option to "Calibrate" settings for best performance, which doesn't need an adjustment once it was run which appears to imply that it runs a test on a specific computer to detect the 'optimal' setting. (while this app does resampling only, no vector data handling for instance)

    gigapixelcalibrateperformance.jpg.63455d3f88f02b361a5e104129fd156c.jpg

    Also this description by James Riston doesn't make it clear to me (with limited technical knowledge) whether there is an 'optimal' either/or setting for general use in a certain setup or whether Hardware Acceleration would 'ideally' need to be switched on/off depending on specific tasks (which is rather uncomfortable for general use but may be useful if specific tasks are in focus / main usage).

  18. 23 minutes ago, walt.farrell said:

    Also, note that the Macro panel is in the Left Studio by default, and the Left Studio is hidden by default in Photo. So, you might also need Window > Studio > Show Left Studio.

    If I choose on mac a menu entry in the Studio menu with the according left/right studio currently hidden then the app auto-switches the according panel dock to visible. No need to choose "Show Studio" before or after selecting the panel in the menu.

    Is this different on Windows?

  19. 3 hours ago, AvdB-Netherlands said:

    Ik heb nu de drukkerij gevraagd hoe zij het pdf bestand hebben verwerkt. Een ding is wel zeker: de instellingen bij mij zijn correct.

    9 minutes ago, AvdB-Netherlands said:

    Dank! Het is voor mij een hele geruststelling om te weten dat de fout niet bij mij ligt.

    If this was the answer of the print shop I would assume they offered a correct re-print, without your need to literally request it.

     

×
×
  • Create New...

Important Information

Terms of Use | 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.