Conditional Data Merge Object Visibility

[mimiduck]

Hi! I'm designing a card game using Affinity Publisher. I'm populating text fields and images using a Data Merge Layout, but I'd also like to toggle the visibility of certain elements on each card based on a field in the Data Merge (for example, show one of three different symbols in the top left based on a "Type" field in the CSV file). Is this currently possible?

[lacerto]

(...)

[Old Bruce]

15 hours ago, mimiduck said:

I'd also like to toggle the visibility of certain elements on each card based on a field in the Data Merge (for example, show one of three different symbols in the top left based on a "Type" field in the CSV file). Is this currently possible?

Myself, I would do the toggling in the spreadsheet.

[Andy05]

53 minutes ago, Old Bruce said:

Myself, I would do the toggling in the spreadsheet.

That's actually the approach, which makes most sense. Affinity Publisher isn't meant to do decisions about what to display or what not in case of data merge. It should be the task for the app which produces the data to decide.

[MikeW]

55 minutes ago, Andy05 said:

That's actually the approach, which makes most sense. Affinity Publisher isn't meant to do decisions about what to display or what not in case of data merge. It should be the task for the app which produces the data to decide.

Really?

The following is from one of the medical directories I do each year. If I couldn't do these using a "prototype" in the merging application there would be a lot of various manual cleanup/work required. This is just one example of conditional merging I do. Others are more or less complex, some also involving tagged text.

That combined with the inability to not merge into primary text frames, choosing master pages depending on variables, etc., etc., inside of APub means for many people, APub isn't a viable vehicle for merge work.

[lacerto]

(...)

[Andy05]

On 10/7/2021 at 4:49 PM, MikeW said:

Really?

The following is from one of the medical directories I do each year. If I couldn't do these using a "prototype" in the merging application there would be a lot of various manual cleanup/work required. This is just one example of conditional merging I do. Others are more or less complex, some also involving tagged text.

[image snipped]

That combined with the inability to not merge into primary text frames, choosing master pages depending on variables, etc., etc., inside of APub means for many people, APub isn't a viable vehicle for merge work.

Yes, really.

Affinity Publisher is a layout/design app. If you need to manipulate data which you want to merge into your layout, do it with a dedicated app.

A data merge option in a layout app is meant to insert data—not to edit, evaluate or manipulate it. Just because other developers try to produce overloaded "can-all-do-all"-apps, it doesn't mean that that's the correct way to go.

[MikeW]

30 minutes ago, Andy05 said:

Yes, really.

Affinity Publisher is a layout/design app. If you need to manipulate data which you want to merge into your layout, do it with a dedicated app.

A data merge option in a layout app is meant to insert data—not to edit, evaluate or manipulate it. Just because other developers try to produce overloaded "can-all-do-all"-apps, it doesn't mean that that's the correct way to go.

Inexperience at best. _________ at worse. I'll let you guess what the "at worse" word would be.

Yes, when it makes sense, I do use Access and/or Excel to manipulate data. But, the type of merges I do, like in the above example, are best using a plug-in/XTension (ID/QXP) that can (1) merge directly into a continuous text frame (which at present APub does do/do well) and (2) can use if/then/or, etc., into that single flowing text frame...or even create objects as needed.

The above example is roughly 450 pages, and among other things, sets the running header variables (something APub cannot do), switches master pages depending on content (something APub cannot do during a merge), creates the TOC based on styles (APub can do) and index entries (something APub cannot do during a merge) creates cross references (APub cannot do), generates See Also links/cross references (APub cannot do), etc., etc. The 450+ page merge is done in minutes and I am left with a publication over 95% finished.

This work would takes days/weeks in APub or any/other layout application that does not have a plug-in/XTension architecture and/or the person using such an application is too cheap to purchase such technology. And, as there are several hundred entries in the above version (some have more for larger states) one would have excessive pages, a thousand or more individual text frames and have a ton of manual work.

But if all that extra work/time suits you and your vision of what a layout application should be capable of, and doing so for the same amount of money--thereby making pennies on the dollar--more power to you.

[Andy05]

5 minutes ago, MikeW said:

Inexperience at best. _________ at worse. I'll let you guess what the "at worse" word would be.

Yes, when it makes sense, I do use Access and/or Excel to manipulate data. But, the type of merges I do, like in the above example, are best using a plug-in/XTension (ID/QXP) that can (1) merge directly into a continuous text frame (which at present APub does do/do well) and (2) can use if/then/or, etc., into that single flowing text frame...or even create objects as needed.

The above example is roughly 450 pages, and among other things, sets the running header variables (something APub cannot do), switches master pages depending on content (something APub cannot do during a merge), creates the TOC based on styles (APub can do) and index entries (something APub cannot do during a merge) creates cross references (APub cannot do), generates See Also links/cross references (APub cannot do), etc., etc. The 450+ page merge is done in minutes and I am left with a publication over 95% finished.

This work would takes days/weeks in APub or any/other layout application that does not have a plug-in/XTension architecture and/or the person using such an application is too cheap to purchase such technology. And, as there are several hundred entries in the above version (some have more for larger states) one would have excessive pages, a thousand or more individual text frames and have a ton of manual work.

But if all that extra work/time suits you and your vision of what a layout application should be capable of, and doing so for the same amount of money--thereby making pennies on the dollar--more power to you.

LOL You're a true Einstein, aren't you? You expect a low budget design app to handle such a specialised task like yours, which even other high budget apps can't do without plugins/extensions, which are dedicated to deal with such tasks? 

Seriously, if you're supposed to transport 30t of goods from A to B, would you expect your low budged street car to do this job, because it "can transport" stuff? Or would you rather take a vehicle dedicated to transport heavy goods, like a huge truck?

Again, data merge in a design app is meant to add prepared data into a template. Your task is not "data merging" at all, you request for "data editing/manipulating, then merge). Different task, wrong app. And obviously, you can't do that in other apps either without additional tools. So what?

On 10/7/2021 at 4:49 PM, MikeW said:

That combined with the inability to not merge into primary text frames, choosing master pages depending on variables, etc., etc., inside of APub means for many people, APub isn't a viable vehicle for merge work.

I really don't get why you're trying to convince me that Publisher isn't the right app for doing such complex and specialised data merge tasks. That's what I was saying since this discussion started. You rather proved me right all the time.

21 minutes ago, MikeW said:

But if all that extra work/time suits you and your vision of what a layout application should be capable of, and doing so for the same amount of money--thereby making pennies on the dollar--more power to you.

What? Where did I say, I'd do such tasks in Publisher at all? To the contrary, I said, Publisher's data merge is NOT meant for such tasks. 

24 minutes ago, MikeW said:

Inexperience at best. _________ at worse. I'll let you guess what the "at worse" word would be.

True. Since you obviously have some experience, I wonder if latter part applies to you as you did nothing but adding more arguments to support my statement. Again, in case you still have issues to understand: "Publisher is not meant to be a tool for editing/manipulating data for data merge." Neither for simple tasks nor for complex tasks like in your example.

[MikeW]

APub is a Professional layout application, yes? Or not.

Plug-in architecture will come to APub. Whether anyone will extend it's capabilities in this direction  or not will be seen after that point. 

The same applies to utilizing tagged text. I cannot imagine doing even simple books without it. 

The same applies to integrating math capabilities. 

And the list goes on.

I don't care what the price is. I didn't choose Serif's price point. If the above and more capabilities are not added over time, APub will be relegated to brochures and simple work or for non professionals with more time on their hands who don't desire or cannot or do not desire to afford an actual professional application.

Relying on an argument based on price for an application billing itself as a professional application is silly. 

[MikeW]

Oh yeah, I forgot something re plug-ins/XTensions.

Those add-ons cannot do what is otherwise available via scripting. In the case of ID, the plug-in I use can completely be handled via scripting. As QXP's scripting capabilities is at best sucks, it has to be handled via an XTension. Most of the above can be scripted in Viva Designer.

APub will get scripting in the future. IF Serif exposes everything that can be done by the application, a script can/could be written to do the above and more without paying what I do for the plug-ins/XTensions. A person just needs to weigh their time/effort/abilities to make the scripting do that.

[lacerto]

(...)

[Andy05]

11 hours ago, Lagarto said:

Affinity Publisher has some smart features implemented in the Data Layout Too

Yes, as a bonus. Not as something, which should be seen as a requirement of a data merge function in a layout software.

11 hours ago, Lagarto said:

IMO Data Merge is easily one of the most potent features of Affinity Publisher.

Indeed. Also one of the most useful, when creating catalogues or brochures for clients, which have a shared layouts for their article groups.

[mimiduck]

Thanks so much for the answers! @Lagarto I'll try the Erase blend mode, that seems like the closest option available. The content I'm trying to show/hide is all built up in designer / publisher, not external images, hopefully it'll work. For this kind of thing I'd definitely love a lightweight scripting language that I could use to have individual elements change/move/etc depending on other content... Hopefully in the future!

Edited October 14, 2021 by mimiduck