Jump to content
Our response time is longer than usual currently. We're working to answer users as quickly as possible and thank you for your continued patience.

mattspace

Members
  • Posts

    66
  • Joined

  • Last visited

Posts posted by mattspace

  1. HI,

    So this is a problem I have when placing PDFs into Publisher - the system's (macOS High Sierra) LCD Font Smoothing engine causes red & blue fringing around the edges of the text. The same problem happens in the operating system's Image processing engine (SIPS). You can alleviate the effect by switching off LCD Font Smoothing in the system preferences, and I've even used Applescript to do this as the first and last stage of a SIPS run, but having to turn it off before placing, and updating a pdf in Publisher is kind of a drag.

    Is there an option to ignore it? I note this isn't a problem for me in InDesign, because it uses its own PDF processing engine.

    image.png.c4960afd653f5ca5f3b83655352485b9.png

  2. 9 hours ago, loukash said:

    Image size has been generally communicated as "width × height" in this particular order since… how many decades? Or even centuries…?
    Also, while you're already thinking  "a few seconds" anyway, you may want to place the cursor over one of the fields and … voilà.

    That all said:

    I definitely agree with you! :)

    Height, Width, (Depth) is the standard order for listing measurements in the art world. The colloquial use of Width x Height only emphasises how important it is that tools are explicit in their labelling of measurements, because people have to swap back and forth a lot.

    In Photo 1.9.1, only the Width field has a tooltip, the Height field produces nothing, but either way, Braille (mouseover hovering) should not be the model for a GUI, emphasis on the G.

    Unfortunately, there are a lot of people in the computing world, who've been lead to believe that decorative minimalism is a substitute for design.

    Cheers :) 

  3. That's interesting, and I can see the logic to it, though the document was started with the preference to "prefer linked".

    The point is moot now however - it seems the update from macOS Sierra to High Sierra fixed a bug I was experiencing in the system's native pdf rendering, which meant the core of the problem, rendering .pdf into .png was able to be done by an Automator action. So I don't need to involve Publisher, or Photo (just means I'll have to virtualise a system with CS5 in it, eventually).

    cheers,

  4. 5 hours ago, thomaso said:

    It doesn't touch your topic but might be of interest: there are various tools converting PDF to PNG, some of them online and/or free, for instance https://pdf2png.com/

    I recall having an automator script that did most of it at one stage, though I think I mothballed it because macOS Sierra had a native pdf rendering bug that put red and blue fringing on text. Thanks for reminding me of *why* I originally bought into Affinity - to get around that issue. I might dig that out and see if I can rework the process.

  5. Publisher 1.9. The files are going through Publisher because Affinity Photo has a bug that prevents it rendering them properly, and I need to get them into png format for epub publishing. InDesign has no png output, and Photoshop CS5 can't have its opening of pdfs automated. So the process is render out the pages as pdfs from InDesign, they're all placed in a Publisher document, then Publisher outputs as png. That way, If I have to change the master InDesign document, I can then run the output script from that, then run an output pass from Publisher, and have my several hundred pngs.

  6. This is the same 236 page document, the InDesign version has linked layered tiff files (and all of the layout, text etc), many of them upto 500mb in size each. The Publisher version is linked pdfs of the pages spat out by InDesign, that are 20-40mb in size. Publisher is set to prefer linked for its file placement, and the files all show up as linked.

    Does "linked" mean something different for Publisher - is it still keeping a full copy of the linked file within the document?

    size.png.1dda0b7dbcd7904b363fd79d34f3de92.png

  7. Hi,

    Not sure if this is a bug, or just a problematic implementation.

    The situation - I have a 230page+ document, every page is a separate placed pdf file. Those pdfs are produced in a different application. I want to make a univeral update, that requires replacing every pdf from the other application. So, in the other application, I run the script that saves out every page as separate files - it overwrites the old pages.

    Publisher seems to be over-enthusiastic as watching for changes for files, and comes up with a modal error for every file, as "unsupported file types", I suspect because it's attempting to read them before the other app has finished writing them.

    not_supported.png.ec9a68e74ac4f1a2f320ebd74ac0746f.png

    As well, it puts up a notification for every changed file:

    notifications.png.d22892c3f33b79cbdcf5407fe59ec339.png

    I ended up having to force-quit the application to get out of this.

    For a single page update, it will throw up this unsupported file type error approximately 3 times in succession once the new file is written out in the other application.

  8. On 2/17/2021 at 6:53 AM, thomaso said:

    The concept of Global Layers is realized already, e.g. in ID. – I don't see a reason nor advantage to have them in a separate layers panel or panels section.
    Once more: Global Layers have nothing to do with Master Pages or Master Page Layers.

    InDesign (CS5 era image) does this nicely - the entries in the layers palette show each entity on the spread, in the layer it's in, so you can adjust the stacking order of elements on the page within Global Layers. But, you can also in single-digit-clicks non-destructively (I can't over-emphasise how important it is that this doesn't actually change any pages) re-purpose the entire document for a different output intent (from anywhere in the document), by toggling layers on and off.

     

    image.png.596b410de47c4dc66bf152c6b4baeb5b.png

  9. As per subject - would be good if Preview mode removed all non-output elements from the page / spread.

    Finding it distracting when trying to work with cross-spine artwork, or bleed to the edge when there's white, or black hairlines that aren't actually part of the artwork, and don't show up in the output, but show in the application.

    For example, InDesign's Preview Mode switches off every guide and UI element on the spread, so what you see is only the canonical output.

  10. 1 minute ago, Joachim_L said:

    No and no. Why do you need this? Perhaps worth a feature request in the appropriate forum?

    Because it looks awful with artwork I have going across the page centre, and it's a thing that doesn't appear in the actual output.

    EG in InDesign, you have Normal Mode where you have all the guides, margins etc visible, but then you can switch to Preview Mode, where it's still fully functional, but you only see the actual output.

    But knowing it's not able to be disabled, I'll put in a feature request, thanks.

  11. Oh something I noticed - when placing this same file in Affinity Publisher, the box edge artefact effect doesn't occur.

    So here's my (current) workflow to get around the problem:

    Original 236 page publication in in InDesign CS5, which I can still run.

    1. I use a 3rd party script to export all pages as individual pdfs
    2. I manually place them, one at a time into a new 236 page Affinity Publisher document.
    3. I export all the pages as .png files
    4. The .png files form the pages of a fixed-layout .epub file that's assembled manually with xhtml files in a text editor (png is used because jpg files suffer colour shifting in black and white from the presence of red & blue respectively, and that will show at the point where the spine meets).

    If I could cut out step 2 & 3 via the issue in Affinity Photo being fixed, and just process all the pdf files out as a batch job, I can get from the end of step 1, to the beginning of to step 4 in about 8 seconds.

  12. i might have fixed it... fingers crossed;

    preferences, miscellaneous: "reset default user defaults"

    I uninstalled the app and reinstalled it, but it still didn't act like it was unlicensed / trial, so there's something persistent - any guides available on how to completely clean Designer out, so that when reinstalling it doesn't act as if it's been installed previously?

  13. Hi,

    This is a bug that effects 1.8 builds and the new 1.9, but did NOT effect the 1.9 beta, and does not seem to effect a different user account.

    Designer is behaving as if it's hard coded to the left hand side of a multi display system. Toggling into separated mode, and back brings the main window back to the middle (main) display.

    I've uninstalled Designer using AppCleaner, which seemed to get a lot of files in ~/Library etc. Then downloaded Designer afresh and installed afresh, BUT it hasn't asked me for a serial or acted like it's in trial mode (which it did when I launched in a different user account on the machine) - so my working hypothesis is that since it didn't effect the beta (being a different application), or a different user account, is there is some persistent file that contains the rego information, and the damaged screen position at  launch, within my working user account on this machine.

    So, what are the locations for every possible file related to designer that contain rego information or anything related to preferences, window positioning etc?

    designer_launch.png

  14. just adding to this, I completely uninstalled (Appcleaner) and reinstalled Designer 1.8.6, and the problem persists on a fresh install, and after resetting the studio. It doesn't manifest in Photo or Publisher:

    Here's what it looks like on launch:

    Photo and Publisher both launch correctly, with the application centred under the menubar on the menubar monitor. Designer is obviously getting the size of the window correct, but it's got what appears to be a hardcoded left edge position to the left side of the workspace.

    I would suspect this is because if it was tested on a multi-display system, those tests were done with "separate spaces for each display" enabled, which prevents windows spanning displays, and as such a hardcoded left edge of zero would theoretically work if the app was launched or moved to the centre display.

    designer_launch.png

  15. 8 minutes ago, walt.farrell said:

    Touch the tablet and begin the stroke before pressing Shift.

    Or (I think) press Esc before touching the tablet.

    ahh yes, ok that seems to be a workaround (though it's not as accurate as snapping to the guides would be).

    Still seems like a "this person has never done the work the tool is designed to do"-level weird design choice, to have raster brushstrokes not able to interact with guides (or any vector shapes?). In a Vector illustration app like Designer, maybe I could understand it (but it would still be a bad idea), but in Affinity Photo... 🤷‍♂️

×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. 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.