Peter Kahrel
-
Posts
26 -
Joined
-
Last visited
Posts posted by Peter Kahrel
-
-
> Those of us who would love to experiment with it early would send an invaluable feedback to the devs, which in my opinion is as important as the release itself. And those who love living on the edge would start using it early and learn what works what what doesn't.
Absolutely. Good point.
-
> I must say thank you for the great book.
Glad to hear it!
-
Many thanks for the progress report.
> Naturally we've been exposing more of the apps' functionality to scripts
I hope the ultimate aim is to expose all the app's functionality to scripting. Can you say anything about that?
When you expose only part of the app's functionality you have to make a choice -- you'll always get it wrong.
- Bit Disappointed and Seneca
-
2
-
That's why a road map of planned features would be useful.
P.
- A_B_C, Helmuth Pandora and Joerg Thoeming
-
1
-
2
-
-
A road map would be interesting.
-
@GabrielM -- I don't have any particular project file, but it's easy to recreate. In a text frame, type xxx, press Enter/Return, and type zzz (but don't press Enter/Return). Now search .$ (any character at the end of a line). This expression should match first the last x, then the last z. But the last z is not found.
Peter
-
Well, yes, but the ones in Miscellaneous are toggles for panels, not text.
P.
-
Search results of expressions that use lookahead and/or lookaround aren't processed correctly. Search results are displayed in the Find panel, but they are not highlighted in the text and cannot be changed by a replacement text.
This is the case with lookahead (?=...), the classic lookbehind (?<=...), and the modern, variable-length, lookbehind, \K
P.
- Alfred and Patrick Connor
-
2
-
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.
-
That symbol is the section sign, it indicates the end of the story.
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.
-
\b works only at word beginning. Given a word 'the' in the text,
\bthe matches
the\b does not matchP.
-
$ matches the end of a paragraph only when the paragraph ends in a return character. The last paragraph in a story, when it doesn't end in a return, is ignored.
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.
-
On 11/28/2018 at 5:05 PM, MikeW said:
The request was for GREP as used in InDesign, which I believe uses PCRE (including in its JavaScript).
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).
-
On 9/12/2018 at 12:12 AM, kimtorch said:
I believe Python would turn existing ID users off - it certainly would me as I don't want to learn yet another language.
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.
Scripting
in Feedback for the Affinity V2 Suite of Products
Posted
> Our priority for scripting is Photo and things like developing RAW files, adding meta data, . . . etc.
> Creating documents and text processing is 'pretty', but it's of zero interest to us compared to the aforementioned raw and image processing which happens every minute of every day and is where the real time savings are.
What complete nonsense. Processing text documents can be as time-consuming (or even more so than) whatever you you do in Photo. If you can't automate various typesetting aspects you'll lose a lot of time.