Peter Kahrel

That's why a road map of planned features would be useful. P.

That's true. But in InDesign you could do footnotes 'manually' because you could script them.

A road map would be interesting.

Well, yes, but the ones in Miscellaneous are toggles for panels, not text. P.

Yes, confirmed. The matches are displayed but not highlighted. And i reported the bug. Looks like a general problem with location markers (lookarounds are a kind of location marker). P.

Thank you, Walt, found it. But since in the interface the item is in the Text menu, I'd have expected it to be in the Text section in the KBSC editor. Miscellaneous would be for things that aren't available in the interface, such as a shortcut (like InDesign's) to activate the last used entry field in panel, a shortcut to close all documents, etc. P.

> There's already an indication. True. But a single button to clear the dialog is still useful. Especially if a previous find/change used a space character as the replace text: you can't see that. P.

In the Keyboard shortcuts editor you can assign shortcuts to a selection of menu items. I think all menu items should be selectable. For example, the Text menu has the useful item 'Toggle unicode'. But that could be made so much more useful if we could assign a shortcut to it. P.

Great, thank you. It's incomplete (e.g. no lookahead and lookbehind yet) and still a bit buggy (bug reports submitted), but it's early days and I look forward to a full implementation. P.

> Some search characters get replaced with an icon. I think that is helpful. I disagree. Those icons take a lot of space and you have to select them from a dropdown every time. They should have text equivalents, such as \r for line break. If Affinity get serious about providing scripting support, text equivalents of those icons are needed anyway. > Maybe a little "reset format" button that only shows up when there is a format set. Yes, that would be very useful. P.

InDesign uses the Boost libraries for its GREP. Those are probably Perl-compatible -- InDesign's GREP is very powerful. InDesign's JavaScript (ExtendScript), however, uses standard JS regular expressions, much less powerful than InDesign's (e.g. no lookbehind, no Unicode properties). Peter

Seconded. Optical kerning is useful to a degree, but the ability to add custom kerning pairs is essential. Quark has that possibility, it's a great feature. Zoot quoted Affinity as saying "We provide kerning based on tables in the font file. As these are pretty well supported by fonts, doing anything more isn't a priority at the moment." Well, Affinity, think again.

I'll add my vote for footnote and endnote support. > Hope you can implement it in a similar way like in InDesign, . . . Please, Affinity, whatever you do, don't look at InDesign's notes. Footnotes are at the document level in InDesign, they should be at the level of the story. That way each story can have its own numbering style and start number. It should also be possible (as it isn't in InDesign), to set the first footnote in a text as an uncued note. And users should be able to define their own sequence and appearance of note symbols (asterisk, pilcrow, dagger, double dagger, paragraph symbol, etc.). > Visit any university library and you'll find that endnotes replaced footnotes long ago, perhaps in the 1950s. Complete nonsense. Academic publishers prefer footnotes. > In the era before computers, endnotes were far easier to typeset. That's why notes were set as endnotes at some stage. Endnotes hung on for non-academic texts and in texts published by penny-pinching publishers, but nowadays footnotes are preferred by many. Footnotes are still more labour-intensive than endnotes, but the difference in effort is not nearly as big as it used to be. > In today's world, their appearance at the bottom of a page is seen as clutter by most readers. In my experience, readers just get annoyed by having to go to the end of the book (or worse, to the end of the chapter in multi-authored volumes).

Probably not. Python support is a popular item in InDesign's feature request forum (User voice). > If Affinity do the syntax and object model right, a lot of existing ID code could even be reusable/transportable which would be a HUGE consideration to switching. That would indeed be useful but is hardly likely to happen.

Seneca wrote: > I don't think that a half-hearted approach to scripting will do. > Do it properly from the start. We should be able to automate everything. InDesign is a good example here. I wholeheartedly agree. Scripting is useful only when you can script everything you can do in the interface. That's what sets InDesign scripting apart from Photoshop, Illustrator and all the other scriptable Adobe applications. In InDesign you can script everything. Photoshop and the others expose only part of their document models, which has frustrated script writers for years. I'm for JavaScript and/or Python. If you go for JavaScript, please add a component that allows us to read and write files.