Jump to content

Peter Kahrel

Members
  • Content count

    6
  • Joined

  • Last visited

About Peter Kahrel

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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.
  3. 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).
  4. 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.
  5. 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.
  6. Fierys, > The typographic problem of "hanging conjunctions" doesn't exist in most languages, including English, because a single letter or digit at the end of the line is irrelevant in them. That's not true. Many British publishers don't like 'I', 'A', and 'a' (the first-person pronoun and the indefinite article) at the end of a line, so you need the same kind of regular expression that you use for Polish one-letter prepositions and conjunctions.
×