mattspace

Thanks for confirming. *sigh* FFS I could do this in Photoshop 14 years ago. Yet another weight on the side of "go back to Adobe"... I can't get tasks done with consumer rights & feeling smug about sticking it to the man.

I've tried everything I can think of, and searched high and low, but it seems it should be a simple thing. I've created some text, I want to apply a perspective distortion to the text to match the forced perspective of something the text is supposed to be sitting upon, so that the top of the text is narrower than the bottom. The text is centred to the central perspective line. How do I modify the drag of one of the top or bottom corner points, so that the corresponding point on the other side mirrors its movement based on axis? Like how to I get both top corners to move inwards towards each other by an equal amount? Thanks.

As per topic - a Studio preset for placing palettes on screen, the free-floating Tools palette isn't included when resetting the palettes to a different configuration.

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.

Trying to get Publisher back into my production process, and instant crash on attempting to open a pdf that Preview handles without pause or issue. Granted Publisher 65GB of RAM to play in, doesn't seem to be a lack of available memory.

This is still a problem in 1.10.1

Noprobs - most of the problem is alleviated by having the main display connected by HDMI, which doesn't disconnect from the system while sleeping. But yes, the current build, you can still drag palettes top edges under the menubar, where they can't be grabbed to drag them back out, however the Studio Presets function makes it a non-issue, because you can reset them back.

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

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.

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,

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.

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.

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?

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. As well, it puts up a notification for every changed file: 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.

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.

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.

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.

ahh yeah, I see, but it doesn't get rid of the page edge / spine lines, which seems a little counter-intuitive. 🤷‍♂️

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.

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,

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.

Just wanted to bump this, because it's still happening in 1.9. Any chance of an update as to whether it can / will be fixed? Thanks.

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?

Further symptom - setting the dock to be at the bottom (on the middle screen) rather than down the left side causes the behaviour to go away in the effected user account. The dock position has no effect on behaviour on the alternate account.

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?