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

Recent Profile Visitors

659 profile views
  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.
  2. 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. This is a pain point whenever doing an export, that allows a mental load to be added to the process, of simply having to take a few seconds to think about which is width, and which is height. A simple addition of "W" & "H" next to each box would be a HUGE weight-off-mind and ease of usability change.
  4. 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,
  5. 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.
  6. 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.
  7. 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?
  8. Yeah, it's set to passthrough, so I'm effectively able to use Publisher to convert pdf to png. It's not quite as embarrassingly fast as Photo was at processing the directory, unfortunately.
  9. 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.
  10. 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.
  11. ahh yeah, I see, but it doesn't get rid of the page edge / spine lines, which seems a little counter-intuitive. 🤷‍♂️
  12. 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.
  13. Hi, Is there a way (setting) to disable the spine / centre line in spreads? Also, disabling the hairline around the edge of pages / spreads? Thanks,
  14. 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. I use a 3rd party script to export all pages as individual pdfs I manually place them, one at a time into a new 236 page Affinity Publisher document. I export all the pages as .png files 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.
×
×
  • 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.