John Hind

Please guys when you add nice new features could you put them in the UI as well as hotkeys. I cannot remember hotkeys so keep not being able to find features I vaguely remember. Even if experts use hotkeys, more casual users find the UI much more discoverable and recallable. For example: The new features around Alignment in 2.4. The right/left option could easily have been a tick box on the existing Alignment drop-down dialog. Selecting a reference object could have been initiated by a button on the dialog with a prompt to click on the object.

Thanks Paolo and Stefano - this suggestion was a very slow burn and I was beginning to think that something fairly obvious to me was a completely outlandish suggestion nobody in the print world would understand! Yet HTML started in the print world as SGML, a semantic markup standard, the semantic aspect got stripped out with structure and presentation merged in early HTML, which then slowly got the point and added it back in in a different form (CSS)! Now the online world has content management and multi-targeted dynamic layout. Time to port that learning back to the print world and unify the two with print, ebook and PDF formats just another automatically generated output format alongside HTML, styled from templates designed by professional designers to a house style. I really cannot understand why Affinity (and other desktop publishing software) gets this so completely for the art workflow and yet cannot carry those ideas over to authoring!

For me, the biggest omission from Publisher at present is support for Linking and Embedding of semantic markup text files. This would allow authored text resources to be handled in the same excellent and flexible way image resources are at present. Authors would be able to round-trip text content between Designer and their preferred text editor software in the same way as artists can round-trip image files at present. Crucially, the files can be either linked or embedded according to workflow requirements. Doing this well requires the following enhancements: Support for semantic markup text files formats such as Markdown and SGML. In these files the author marks up passages according to what they mean not how they look (for example 'Heading 1', 'Bullet List', 'Emphasis'). Designer is responsible for converting this to a particular typography to implement the style of the document. Support for Style Sheets. These are collections of text and paragraph styles which get mapped onto the semantic markup to determine the look of the document. You apply a style sheet to a Text Frame in the same way as you might a filter onto an Picture Frame. Handle text files as resources using the feature set already implemented for image files. They should be updatable, replaceable, linkable, embeddable, collectable etc. For 'extra credit' handle visual markup formats (DOCX, PDF, RTF, ODF, XML etc.) in the same way using AI to strip away the visual markup and reinterpret it semantically. Fairly straightforward if styles are used with discipline in that you just overwrite the definition of the styles. Harder if the markup is applied in an ad-hoc manner in that you have to infer semantics. If Publisher was able to implement something like this it would, in my view, go from good to great and support more professional workflows such as production of serial publications with multiple authors and editors.

I'd not realized 'printed' meant 'exported or printed' - that does make it a bit more useful in this specific case. Still leaves the 'Date & Time' field not really doing anything useful as currently implemented.

This begs the question "what is the intended use case for the Date and Time field as currently implemented?" At the moment the implementation is schizophrenic: you can update it per occurrence, but only to the current date and time and multiple occurrences can be different if they were last updated on different days. If it is a 'current date and time' all the occurrences should be the same and either automatically update or at least have a single action to update all occurrences. If it is a general 'Date and Time' field there needs to be a way of picking a date and time other than the present (word processors often have a pop-up calendar), and in this case it makes sense for multiple occurrences not to be synchronized. My general use case for fields is for templates. Ideally, when I create a document based on a template I do not want to have to edit the master pages, especially if a text substitution occurs multiple times such as a title in the header of multiple master page layouts. This is why I raised a feature request for user-defined fields so the template designer can define them appropriate to the specific document type. But meantime, the existing fields can be used that way, for example for a product brochure the template designer could specify that the 'Title' field be the product name. Fixing the bug on Creation Date will address many of the use cases for a date field, for example the date on a letter probably wants to be the date when you created the file or perhaps the printed date. But a use case for Date and Time might be 'publication date' which would not necessarily be the same as any of the automatic dates. But this is of very limited use if you can only update it to the current date and you have to do this update individually for each occurrence in the actual text (which may be in the master pages).

Thanks for logging the Creation Date bug. Regarding the Date and Time, I still cannot see the point in it being a field if there is no automated or centralized update. May as well just be a text insertion macro. One way of making it more useful without a breaking change would be to provide 'update' buttons on the Fields panel. This could be against the specific updatable field types (those with update buttons on their 'Edit Field' dialog) and/or a global button to update all updatable fields in the document. Also the facility per template to set auto updating of fields on creation of a new document from the template.

Yea, sucks to be a software developer! Case in point, they put in templates and now annoying people like me want them done right! Simultaneous teamwork is certainly a harder case probably requiring re-architecture of the file format (unless they planned ahead for this). However waterfall workflow is a valid use case. In my case I actually wear both hats but it is useful for me to separate my work into template design followed by document design. This is because I will produce many documents from one template and this approach saves time, maximizes consistency and reduces cut-and-paste errors..

I'm baffled. I definitely saw a situation where the 'Expand Field' and 'Edit Field' context menu options were available and the Edit Field dialog appeared but the the 'update' button and the format drop-down did not change the field text. However I have been unable to repeat that behavior today. I've inserted a video showing creation of a document from a template. This was done today (6th May) from a template created yesterday. Note that the Document Statistics fields for the new document reflect the file details, including creation date, of the template file until the new document has been saved. This contrasts with creating a new document from a Preset where the 'Created' field is initialised to the current date and the filename and path are blank until the document is saved. It also strikes me that the 'Date and time' field is not very useful if it has to be manually updated, particularly if there are several occurrences and they might be on master pages. If you have to locate them all and manually update each of them you may as well just put them in as ordinary text and use find and replace. PublisherField.wmv

Publisher 1.8.3.641, Windows 10 I created a template with a Date & Time field (the one in General Information tagged <Current Date & Time>). When I create a new document from this template the field does not update and continues to show the date when the template was created. If I right-click on the field with Frame Text Tool and click on 'Edit Field' nothing on this dialog changes the text displayed by the field, 'update' button has no effect and neither does changing the format drop down Further to this, I tried the 'Created' field in 'Document Statistics' instead. In this case the date is not updated when a document is created from the template, but is updated when the document is first saved (so the field should properly be 'First Saved' rather than 'Created'. With this field, the 'Edit Field' dialog has no 'update' button, but it does respond to changes in the format dropdown.

You are not wrong. I've long been dissatisfied with the distinction between word processors and 'publisher' style apps. Lack of clear thinking about workflows has led to huge, unnecessary feature overlap between the two and important missing features in the gap. I hoped using 'publisher' would enable me to drop word processors altogether and in truth publisher just needs a few relatively trivial features to make that work. As usual, Microsoft has a lot to answer for as everyone is following their way of doing things rather than thinking about workflows. I see two distinct professional document workflows: A: The few-to-many workflow typical of book production or maybe catalogs, advertisements or static web sites. Here an author produces text and passes it to a designer who lays it out to a publish-ready form. Then many people consume it. B: The few-to-few workflow typical of business proposals, letters, low-volume product datasheets etc. Here a brand designer and/or a business process developer makes a template which is passed to operations staff to fill in the content for many documents each of which will be read by just a few people. The processor/publisher distinction seems designed mainly to serve A, but over time the processor part has suffered feature creep far into publisher territory, but not far enough to make publishers obsolete. B is not well served at all because the template features of both processors and designers are under-powered afterthoughts. Affinity's common file format offers a way forward. Just as there is Photo and Designer to prepare graphics assets which can later be laid out by Publisher, there should be a new Author tool used to prepare text assets, in the common file format, without all the distractions of layout and formatting (a simplified word processor). This could be used either starting with an empty file so the text would later be used in Publisher to complete the layout (type A workflow) OR it could be used to add the text to a pre-existing template produced in Publisher (type B workflow).

Furthermore, it does not seem to be possible to delete embedded assets. Now I tried this in my template file and deleted the asset again but I still get prompted to import assets every time I create a document from that template. Feature badly needs a re-think IMHO!

Thanks, that works but is not quite ideal in the way it is implemented. It imports embedded assets into the user's assets collection (optionally) and does not remove them again when the document is closed. Ideally I would want the assets to be displayed and available while the document is open without the user having to choose to import them. The assets panel should separate 'document assets' from 'global assets' which would also make this feature more discoverable.

Yea, like that's going to happen! I want the template designer to be able to configure it so it just happens for the document author, however they decide to add pages including letting them just type as they would in a word processor. Generally I'm looking here at a designer/author model were a brand designer makes templates to control the branding and product marketeers add content to templates to make specific product documentation.

How? According to the help file, assets are global for a specific user (but can be exported and imported by another user). I want it so any user can create a document from a specific template and get assets saved with that template. These assets would be displayed along with any global assets the user had from the current system.

Hi, The new templates feature is much appreciated, but some more features are needed to make it truly useful. I'll post these separately for easy tracking: 3. Option to store assets in Document/Template file. The existing global assets feature is useful, but sometimes assets are specific to a specific type of document rather than a specific user or group of users. It would be good if there was the option to specify assets as global or document specific. The latter would be stored in the document file and hence more usefully in the template file. More to follow.

Hi, The new templates feature is much appreciated, but some more features are needed to make it truly useful. I'll post these separately for easy tracking: 2. Automatic text flow splicing on insertion of new page with master. For documents like books and letters it is necessary to add pages as the amount of text increases. A master can be used to set the format of extension pages and masters can be put in a template. However when a new page is spliced in, the text flow is not automatically spliced. To make this work it would be necessary to define 'input ports' and 'output ports' on the page templates which would link to the Text Frames on the template page. The input ports and output ports could then be automatically spliced when a new page was inserted either at the end or in the middle of an existing sequence. With this infrastructure it would also be possible to have a mode similar to a word processor where the document automatically extended by adding new pages when the text overflows. More to follow.

Hi, The new templates feature is much appreciated, but some more features are needed to make it truly useful. I'll post these separately for easy tracking: 1. User Defined Fields. Extend the existing fields feature to allow the user to define their own text substitution fields which will be stored in the document and template files. Use case: We define a product brochure template and make the product name a field. This appears multiple times in Masters for example as headings, headers and footers, in boilerplate text etc. If the product name changes or the user creates a new document from the template, the product name only needs to change in one place. Less chance of embarrassing 'cut and paste' errors. More to follow.

I recently purchased Photo from the Windows Store and frankly there was one big disappointment: it has major useability problems in Tablet Mode (in my case on a Surface Book 1st Generation). Rightly or wrongly we have come to associate Store apps with Tablet Mode, so it comes as a bit of a shock to find one is just an old fashioned desktop app! On the Surface Book there is basically no ergonomic way of using the keyboard/touchpad at the same time as the Surface Pen and losing the latter is a huge bummer for a graphics app! After getting over the initial disappointment, I did reflect that a couple of relatively minor improvements would make it a lot more usable: 1. UI Scale settings. The app is much more touch friendly if the UI is set to 300% (rather than the recommended 200%). But this is global and wrecks other apps which are scaled properly in the first place. So what is needed is a UI scale setting within the app. On Windows 10, there should be two settings, one for Desktop mode and another for Tablet mode with automatic switching between the two. 2. On-Screen Modifier Icons. The keys that are used as pointer modifiers (shift, alt, ctrl) should have on-screen icons to make up for not having a physical keyboard. These could usefully be ranged at the bottom of the toolbar convenient to the left hand with the pen held in the right.I suggest these work in two ways: either touch and hold them like a virtual keyboard key; or, on machines were touch and pen are distinguishable, it should also be possible to touch the icon with the pen and then the shift state would be toggled until the pen is tapped elsewhere on the screen.