Frank Jonen

Here you go: CPU: 3,7 GHz Quad-Core Intel Xeon E5 GPU: 2x AMD FirePro D500 3 GB OS: 10.14.6

I copy and paste the objects via copy and paste. Every time I paste an item that has been in a Constraints Group and group it again in another document, that becomes a Constraints Group as well. It effectively poisons the group.

This hasn't been fixed since 2017.

Anything yet?

Hi Chris, I made you a simple file in Designer, opened it in Photo and already saw the first issues from the Layer Effects, then added a Live Filter and broke the rest. To test it in Photo you can just turn off the Live Filter in the First Artboard. That'll show the FX issue by itself. FYI. I'm working in Publisher's Photo Persona now. As annoying as it is to set up everything there again, at least I can work. bug test.afdesign

I should add: This affects Layer Effects as well. Especially Gaussian Blur.

One of the changes with 1.10.0 is that I can't use any of my old Photo files anymore. BTW this gets even worse when you bring files with multiple artboards that have live filters in. This is specific to Photo. The documents work in Designer. Workaround: I've created a document with all of the filters in their default state and bring that into Designer to copy and paste from so I can work.

Your document being in RGB actually solved the issue. The bug only presents itself in CMYK mode. There the colour either stays or jumps to white fill.

I mean white as in white. Opaque. When place the text, it fills the new copy with white. To keep the text intact I have to either place the object last in the layer stack or multiply it over. The previous behaviour was to remove the fill. The new behaviour is to set the fill to white.

That's it. That's the bug. Take any curve and put text on it. Boom, curve is now filled white with no way to fix it manually. Only way to address it is by converting to curves and fix it then.

I thought about sending you the whole project folder with all data files and assets. This document seems to highlight al lot of shortcomings and bugs. I have to fight through the stuff first though since I have to get it out by tomorrow.

Case: Upon completing a layout with data merge elements in it, the generated document only has up to two sections surviving. Both have the same name. When you don't have a restart in numbering to account for title pages, there's only one segment surviving. Repeatability: Always.

If you could explain your complications, maybe I could help. I've done it in TeX with either Python or Go and was quite surprised it didn't work in Affinity. Especially as I'm not a programmer by trade and managed to get it done anyway. If it helps, these are the options I use for mismatched array lengths: As is (98% of the time): Let all arrays run their course, what goes into next pages, goes into next pages. What ends, ends. Example 1: I have nested arrays that just contain pre-sorted file links (like a gallery or chapter files) these are read to finish into their template position within the main template before it advances. Example 2: Sidebar content has more separate items than the main content area. If it overshoots I just place a limiter in or re-write the content. Lead: I'm reading the number of array items of the lead file and use that as the array lengths for all the others. It's a rare use case but it's useful if you have a scaffold layout and need to match hard-breaks. Start / End items are cascaded through. Also I'm targeting the outputs file-unique (using named aliases because I'm lazy) instead of reading all fields globally. It avoids a lot of headaches and keeps you from creating dead-end solutions.

Nothing happens when I open the hyperlink panel, place the cursor into the URL field and double click the field carrying the URLs.

Right now the TOC creation is very hands-on almost completely manual labour because Publisher gets in the way so much. It's atrocious to be kind about it. Also it doesn't create proper PDF TOCs but bookmarks, they show up where the consumer doesn't expect them (in bookmarks instead of the TOC area). This creates unnecessary support tickets. The document sections aren't honoured at all in the TOC creation. The TOC tool itself is quite barren in terms of usefulness. There is no way to define parent/child relations of headings at all. It's all just a jumbled up pile of text boxes that's loosely referenced by anchors that may or may not be placed in the right area. Sometimes the automation even gives me a bunch of page number entries that I have to manually take out again. This area of Publisher is seriously bad. It's the worst TOC creation tool I've used since TOCs were added to the PDF spec. It needs a lot of work before Publisher can be used for end user products.

Probably just an oversight (as is the tiny click box for the trash bin) but it's not possible to clean up the mess that the app makes by itself when randomly generating anchors all over the document. It is vital to be able to manage document structure properly for documentation PDFs when the anchor automation is this bad. Right now the only way is to export all pages to separate documents, load them into a TeX setup and properly generate the navigational structure for the PDF in a way that makes sense for the end user of the PDF. Publisher can't do it on its own.

It would be really great if we could also use data input in living documents instead of baking it out being the only option. If you slap the Find and Replace on top of that, you'd be making history. Real example: For my CV redo I used JSON for almost all of the input, so it's a breeze to keep it updated. Right now that's: Update > Generate > Run "Find & Replace"s to parse the Markdown elements > Export to PDF. This is a pain point as I'm held back by having to create a wholly new document with each update. Having the Data Layout with a second tool to use live data (similar to the data set preview) would really change things for the better in magazine publishing for example. You'd have one person editing the data in a table while another is editing the text and the layout artist sees it all come together live in the layout, like externally updates images. If we then had module options to parse the string data for things like "\i" for italics in Rich Text or "* *" for emphasis in Markdown it'd be hard to overstate how big of an impact that would make. Suddenly editorial systems would be trivial to create and for the first time they could be truly open.

Yes Yes Yes Create an empty document Draw out a data merge layout of your choice on page 1 Create a picture frame in it Link the resource from Data Merge Create more pages with similar setups, doesn't have to be images Go to a page other than page 1 Advance the preview data It will jump to page 1 with the picture frame selected (and its contents distorted) Happens every time without fail.

The document jumps to that very Picture Frame every time when a Data Set is advanced or retracted anywhere in the document. Removing the frame solves the issue. Creating a new one brings the error back.

Currently we have to work around this bug by limiting the page range because all value pairs are global. This could be fixed if the data sets would be referred to by their file name instead of loading all the files at once and telling the files where they can be loaded instead of referencing from where they're needed. Example: source.json:string_name This would also make the Data Merge more robust and enable it as a normal object that doesn't require everything to be baked into a new document.

How to get there: Set up a Data Merge layout grid. Pop the image path from your JSON file into the image placeholder. Set the Picture Frame Properties until it looks the way you'd expect your image to look. Refresh the Data Set or jump to the next entry The image distorts more with each refresh or entry switch

And if my grandma had wheels she'd be a bicycle. This was about Designer, not Publisher.

Any news why this is being ignored by Serif? It's pretty much the only illustration tool without a search. Even Inkscape has search.

Going by most user friendly and easy to read/write, cross platform, most connectivity to other application, there really isn't another choice but Python. It became the lingua-franca of inter-app communication (despite D-BUS) and in-app automation. I think Adobe might have been the only ones who run JavaScript embedded into a desktop app (outside of browsers and browser-based apps). As far as adoptability: I don't think JavaScript/ECMA has ever been accused of being user friendly.

Especially with the new 3D view and texturing enhancements this would make a lot of sense. A brush, driven by Python and/or OSL. When it is applied to a curve it follows it. When it is brushed on, it can leverage additional parameters like tilt/pressure and speed/velocity. Similar to the procedural texture layer it should have a few examples and then let the user pop out a text field to paste in (and modify) their own code and attach variables to UI controls. This could be made available for fill-layers as well.