it seems that the tradition is maintained. I can see at least two roles for the central number (“cotage” in French, I could not find the English equivalent):
Legal: all music pages, including the copyright page, are stamped with this number. Maybe it is a way to state that the copyright applies to all these pages, like for these contrats where one must put a mark on each page before signing the last page.
Practical: imagine a printing shop with a long table and many scores waiting to be bound. If a page falls on the floor, the central number will help the worker (who does not necessarily read music notation) to put in the right stack. This is also useful at home: on a piano, there are many scores printed from IMSLP and suddenly (gust of wind or children), all sheets of music are on the floor.
Thanks for the tip. I was applying the instructions given in “Hiding/Showing borders on layout names” and the borders did not appear.
It took me some time to understand the problem. The basic reason was that {@layoutName@} is not a layout name, unless told explicitly. This may be quite surprising for new users.
When a user creates a new text frame and inserts {@layoutName@} inside, Dorico does not guess automatically it is a layout name. It considers it as default text, and the user must do additional actions to change it to a layout name. In international versions, this is even more challenging, since the user must guess that {@layoutName@} must be mapped to something else (e.g., “Nom de la disposition”, in French).
Thus, I can modify and rephrase my suggestion #6 as follows. There is no bug, but Dorico could be much more user-friendly.
6. Proposal: Many tokens (e.g., {@layoutName@}, {@projectLyricist@}, page numbers, etc.) are naturally associated with a paragraph style that corresponds to them. When the user inputs these tokens, Dorico should automatically use their corresponding paragraph style, rather than Default text. This would not be a conceptual revolution, as Dorico already tries, in some cases, to guide (or force) the user to provide coherent input (e.g., by selecting the right lock for certain frames as soon as the left lock is unselected). If there are several tokens in the same frame, the first one could impose its paragraph style. Of course, an advanced user could always change the paragraph style of token to a different one (which is needed in the default part template, where non-first pages have the layout name associated with the “Heading” paragraph style). Finally, there could be proofreading checks on page templates too, which would report issues in the proofreading panel (e.g., when a {@projectLyricist@} does not have the “Lyricist” paragraph style, etc.).
I’ve been using Dorico since the beginning, and I’m a normal user. I’m not sure what you’re trying to explain here.
A token is a simple placeholder. If you include a token like {@layoutName@}, it will display the name that you gave the layout.
I’ve never encountered any issues with this, so I’m not sure what the “mystery” is about. To avoid mistyping, you can use the right-click menu. I’m sure this is a basic feature that you’re familiar with.
I think he wants the layout name token to automatically pick up the Layout Name paragraph style. (And the same for other tokens.)
There’s a section in the manual on hiding and showing borders on layout names. This only works if your layout name token has the Layout Name paragraph style, and it’s true that this is not made obvious by the manual.
I would like to keep it as it is now, and to have the freedom to use a token without it automatically getting a style as well. You might want to use the token in some other text frame, even in a block of running text.
It’s easy enough to assign a dedicated style after the fact.
You may well want to display {@layoutname@} at the top left corner of the first page, always on the left, at a particular size, and to also display {@layoutname@} on the inside or outside in the running header on subsequent pages at a different size. Same goes for {@projectTitle@} or {@flowTitle@} or even {@projectComposer@}.
Automatically linking the token to a specific paragraph style would be a hindrance in these sorts of (absolutely common) scenarios.
My proposal would not remove, by no means, this possibility of having the same token in two different frames with two different paragraph styles. I explicitly mentioned the case of {@layoutname@} having the paragraph style “Layout Name” on first pages and the paragraph style “Heading” on other pages.
Currently, Dorico always sets the paragraph style of text frames to “Default Text”. This has two drawbacks:
Novice users will keep this Default Text and just change the font size and/or font style, like in Finale.
Advanced users who need, e.g., to implement the scenario you describe with {@layoutname@}, will have to perform two operations: changing from Default Text to Layout Name on the first page and from Default Text to Header on other pages.
With my proposal, Dorico would automatically set up correctly the style of the first page to Layout Name. So, novice users would directly benefit from the right approach and advanced users would have nothing to do. But, at the top of other pages, the {@layoutname@} would also be in Layout Name, and thus in a framed box. It would thus be obvious that something must be done, and only one operation would be needed to change it to Header style.
To summarize, the Dorico concept of paragraph styles makes sense and builds upon the established principle of separating contents vs presentation (which has many incarnations, e.g., HTML/XML vs CSS). However, at present, Dorico makes little attempt at promoting this idea and provides no automated support or guidance to produce page templates in which paragraph styles are set up properly (i.e., different from Default Style). This is why I suggested:
Automated discovery of the most plausible paragraph style for a given text input,
A posteriori checks that trigger warnings e.g., if the user has left Default Style everywhere, if the user has set a bizarre paragraph style for a known token, if a frame contains tokens of different “natural” styles, etc.
The advantage of Dorico always setting the Paragraph Style to Default Text is that it’s consistent and thus predictable.
It’s also consistent with the leading word processors: Microsoft Word and Apple Pages. In each, if you insert e.g. a page number widget or a title, neither of those programs automatically changes the Paragraph Style of either to anything - it’s up to you to change it from “Body” to something else. Same goes for text inserts in Finale.
The default Page Templates in Dorico contain various tokens that are each set to sensible Paragraph Styles, which should at least nudge people in the right direction, even if there’s nothing automated.
I’d bet actual money that if a token inserted on one type of Page Template behaves differently to the same token inserted on a different type of Page Template, novice and advanced users will be confused.
edit: apologies for the sentence immediately above this one; I misunderstood what you’d written - you’re asking for {@LayoutName@} to consistently default to using the Layout Name Paragraph Style, not to behave differently automatically on different types of page templates. I’m still not convinced that this wouldn’t cause frustration. I’m used to typing headers that can actually be quite lengthy; stuff along these lines isn’t unusual:
In this sort of situation an automated something dealing with a single token (or, given that this is how Paragraph Style currently work, the whole text block) would create friction.
And if the answer to that is that the automatic thing should only apply when the only thing in the text frame is the {@LayoutName@} token, we’re back to inconsistency.
The current Dorico approach (putting Default Text everywhere) is simple, but I would not call it consistent. It is just the quick and easy solution to put a “don’t know” (or “don’t care”) value everywhere, a solution chosen when one spends no effort finding a more appropriate answer.
Actually, if one looks at the various frames of the Default page templates, none of them has the Default Text paragraph style that Dorico sets automatically everywhere. Thus, a user designing a page template must change all these boxes manually, and make sure not to forget any of them. I see only two places where the Default Text style could be relevant: a composer’s biography or an elaborate copyright statement in 2 or 3 sentences.
The approach I propose would be deterministic too (the same input in two different frames would produce the same paragraph style) and consistent, in the sense that most frames (95%?) of the Default page template would automatically receive the correct paragraph style.
Your comparison with Microsoft Word and Apple Pages is interesting. Yet:
The context of Dorico is quite different: Word and Pages handle documents with lots of “real” paragraphs, whereas Dorico page templates have no, or very few, paragraphs. Normally, a “real” paragraph consists of several sentences, each sentences having a subject, a verb, and a complement. Dorico calls frame contents “paragraphs”, but most frames in Dorico’s page templates do not qualify as paragraphs.
Word and Pages are not so “predictable”, as they are actively scrutating the user’s input and taking decisions at run-time to change this input without asking the user (who can still undo unwanted changes). There are at least three examples of this:
a) When one types something starting with “http://…” or “https://…”, the word processor automatically changes the style to a URL.
b) Spelling checker and auto-correction also change the user’s input, e.g., by turning letters to capitals after a dot.
c) Word’s “text predictions” and Pages’ 'predictive text" try to guess the end of the words the user is typing.
Millions of users are already familar with such automated interactions with word processors. Compared to the advanced features of Word and Pages, my suggestion of guessing the paragraph styles automatically in Dorico was really modest.
Indeed, if a text frame contains several tokens, each with a different “corresponding” paragraph style, the situation is more complex and a decision should be taken. My proposal was that the first token would impose its paragraph style to the entire frame. Another solution would be to chose Default Text for the frame (which would be justified, here). In any case, the user should be able to update the paragraph style manually.
The problem with this is that it is not going to know what the first token is when the frame is first created, because it will be completely empty. So for your proposal, it would have to forcibly reformat the frame when the token has been entered at any point after the initial frame creation.
In this event, what prevents it from forcibly reformatting a frame that the person has already done lots of formatting on? Because they’ve maybe now edited it to add a token that wasn’t there before and now the “first token” is different and now it has completely obliterated their formatting to replace the style on it. What if the person actually wants “Default text” and now it has thrown that out? You’d have to ask the person “I see you’ve put in a token name, do you want to re-format this for the normal style for this token?” as a popup after every single edit you make to the frame, but I think this would get annoying fast.
The only way I could see this type of thing working at all would be if it wasn’t the act of typing the token name that did this, but instead to provide options when creating a frame “what type of frame do you want to create? default frame, layout name frame, (whatever other options you need)”. Templates for frames, as it were, and maybe they could already be preformatted and preloaded with the appropriate tokens in this case.
I’m not saying I want that either (or at least I don’t really think it’s that important), but it is less bad to me than the idea of fighting against some auto formatting thing that thinks it is too smart for me and wants to restyle something already gotten to look how I want just because I’ve added a token to it after the fact. And, certainly, creating frames should be a less frequent task compared to editing them.
I imagine if they did add such a thing, they could always do a “use default always and don’t show this again” checkbox. Then it would be more or less like the new feature in Dorico 6 where you double click on a title etc to try to edit it directly that redirects you to Project Info (but you can disable that).
The user creates an empty frame. Initially, the paragraph style is “Default Text” (as it is now).
The user types the text: "Arranger: ". The style remains “Default Text”.
The user continues typing and inserts {@flowArranger@} or {@projectArranger@}. The style automatically switches to “Arranger” (assuming this style exists).
The user continues adding text. The style remains “Arranger”.
So far, the style has been entirely guessed by the software, without intervention of the user.
Good point. If the user is not happy with “Arranger” and wants a different style (e.g., “Default style” or “Composer”), then the user changes the style manually using the standard dialog box.
The software should now remember that this style has been manually set by the user and thus should disable any future auto-formatting for this frame.
Ideally, a red triangle could appear in a corner of the frame (same as for page templates) to indicate that the style has been manually set by the user. This triangle could also appear if the user does other changes in this frame, such as changing the font size, etc.
No. Dorico already does a lot of auto-formatting in the music frames and this is done automatically, without many pop-us. Logically, textual frames should use the same principle: autoformatting takes place automatically, unless the user manually imposes a given paragraph style. If there are questionable user decisions (e.g., page numbers formatted manually using “Composer” name), a warning could appear in the proof-reading section, which the user can hide by clicking on the eye.
A small issue is the following: if a text frame is in autoformatting mode and if its current style is “Default Text”, perhaps the dialog box does not allow the user to manually force “Default Text”, since it is already the current style. Then, “Default Text” would remain: it would not be manually selected, but this would be harmless. Only if the user inserts a style-changing token (e.g., {@flowArranger@}), then it will be possible to set up manually “Default Text”.
This isn’t the way it would end up working in practice, I think. If there is processing that Dorico has to do after every letter you type to try to find if you’ve added a token somewhere, it could easily impact the typing speed with a frame that contains a very large text block. If such a thing were to be programmed, it would almost certainly be handled by applying the formatting when the user leaves edit mode for the frame (by only checking the frame contents then). So the scenario would probably be more like:
The user creates an empty frame. Initially the paragraph style is “Default Text”.
The user types the text: "Arranger: ". The style remains “Default Text”.
The user continues typing and inserts {@flowArranger@} or {@projectArranger@}. The style remains “Default Text”.
The user continues adding text. The style remains “Default text”.
The user leaves edit mode for the frame. The style suddenly changes to “Arranger”.
There’s a different issue. It would no longer be possible to insert any token into any frame where you want to use Default Text. For instance:
Create a frame with Default text and add a token.
Upon leaving edit mode for the frame, it would automatically change style to the style for the token, say “Arranger”.
You would then double click on the frame again to re-enter edit mode and select everything and change back to Default Text.
Then you would exit back out of edit mode and it would automatically change style back to Arranger on you.
Yes, auto-formatting of text is a completely different thing than auto-formatting of music and would require completely different code.
Dorico’s auto-formatting of music also doesn’t change what you’ve written after the fact. I know it seems to some new users like it does this (they accuse the program of changing what they wrote because it “thinks it knows better than me”), but that’s because of a fundamental misunderstanding of how it works. What you are asking for the text formatting is for Dorico to do just this - to change what you’ve asked for after the fact because it thinks it knows better.
Word and the other MS Office applications do this sort of thing because they have other related features (spell check with auto-correct, grammar check, etc) that also need this. I’m sure it took some very careful programming even then to make sure that it more often did what users would want than not, and that users had an easy way of “backing out” of anything that it did that they didn’t want. Microsoft has a big user base for testing new things like this for MS Office, so it is easier for them to get a reasonably comprehensive set of user tests. Even still, sometimes MS Office does this to me (auto formats something a way I didn’t want) and I have to hit Ctrl-Z to undo, which thankfully fixes it in most cases.
I feel it would only make sense for Dorico to support this “live” auto formatting of text if there were related features added around this like spell check, grammar check, auto-correct/auto-replace of common typos or things like the copyright (c) with the proper copyright symbol character. Even then as I said it is a ton of work to design such a thing in such a way that it doesn’t get in your way or prevent you from doing things. So it makes sense for something like MS Word where this is the main point of the application, but for Dorico it seems a lot of work for something that is really a secondary feature.
Dorico’s code seems to be better optimised than it once was, but in larger projects interactions with the Page Template Editor can still be somewhat laggy, and interactions with frames on one page template can affect linked frames on other page templates and may affect many pages across multiple layouts.
The idea of Dorico doing something on my exiting a frame, requiring me to then go back in to edit that frame again, fills me with dread.
The idea that exiting a frame may alter the formatting of the text within that frame, which might affect the line breaks within that text, or even whether the entirety of the text is visible, fills me with dread.
I guess it’s reasonable to accuse me of being an old hand, afraid of change - I’ve worked in this program for nine years - but this reads like a feature request that simply hasn’t been thought through.
Thankfully we can rely on the development team to think through implementation.
I’m not advocating for this at all - quite the opposite. I just think there’s a disconnect between what he’s asking for and what he would actually get. He’s asking for a MS Office-style autoformatting that happens live, which would only make sense to me if Dorico used the same facility to implement spell check, grammar check and autocorrect functionality, and provided undo within individual text edits so that you could undo any autoformatting - otherwise it might be a ton of work for some tiny feature. An auto-format on exiting the frame I suspect would be easier to accomplish, but would be terrible for the reasons highlighted in my post from several hours back. Maybe a full MS-Office-style live spell check, grammar check, auto-correct and auto-formatting mechanism might eventually make sense, and this could be OK, but is that really more important than some engraving features that some users still need? Or even playback features? I would personally rather see a bunch of engraving and playback features prioritized rather than that (although I don’t know what the broader user base thinks).
These types of half-baked requests reminds me of a recent thread with the Cubase Score Editor (based on Dorico). People were really upset about the auto-note-spelling algorithm from Dorico spelling notes as E# by default in some circumstances. So they asked the developers to change it so they would “never see E# by default”. So the developers did just this - and then the same user(s) proceeded to get upset after they updated when they opened a previous score in F# major and saw F naturals instead of E sharps. The developers simply did what was asked - but now the users were angry that the developers literally did what they asked them to do. That’s why it is usually better to ask “can you find a way to improve this pain point?” rather than suggesting an actual course of action, unless you’ve really thought it through in all detail (and including all potential pitfalls etc). I’m sure if those users had said “we’re getting E# too easily, can you do something about that?” the action taken might have been different (and the results more agreeable ultimately to the users).
I don’t think that there will be noticeable overhead on speed if the typed input is scanned in real time to detect Dorico tokens. There are only a few tokens; their set is predefined and fixed, so, one can pre-compute a small finite-state automaton that recognize all these tokens. The recognizer cost is linear in the number of typed characters and does not depend on the size of the whole text block. The same already works in many text editors, who dynamically scan user input to detect URLs starting with http://. Similar things are done in this forum with the mark-down language.
This is doable too, but with the added difficulty to determine when the user is leaving a frame. There is no “Close” button on each frame, and there are different ways to exit, e.g., by closing the Page template editor, by switching to another mode, by clicking in another frame, by saving the file, etc.
The problem is that someone might make a typo in a token, like {@projetArranger@} or something, and then if they added the missing “c” to project later it wouldn’t work because there was no space pressed afterwards. So it would have to scan the entire text block every time any character is typed anywhere.
