Previously I use Dorico to type English matters in most case. Now I deal with things written in Japanese, and I found that certain OpenType features are necessary. I would like to see future releases of Dorico (maybe since Dorico Pro 4) support all East-Asian OpenType features listed on this webpage:
I personally need the following:
Proportional Widths (pwid)
Proportional Alternate Widths (palt) // Necessary if typing a Chinese article with condensed Japanese paragraphs quoted inside.
Proportional Kana (pkna) // Only certain Japanese fonts support this function. Source Han fonts only support ‘palt’.
I believe that ruby texts (furigana) in Japanese is also necessary.
Here is a reason of supporting proportional Japanese typography: You westerners may not want to see every texts typed in your language displays in full-width monospaced format. This is how Japanese texts look like without the proportional kana.
P.S.: One more thing related to Western language typograpy: I do believe that some of those who use Georgia may want lining figures in lieu of oldstyle figures, hence the necessary of supporting ‘Lining figures (lnum)’.
I’ve mentioned this in other threads, but it would be great to see Dorico support OpenType features in all languages — I use these features often in my work, and it’s important for Dorico to encourage good typography.
At present Dorico is limited to the OpenType features supported by the Qt application framework. I certainly don’t rule out the possibility that we would implement support for more OpenType features ourselves, but it’s not something we are likely to be working on imminently.
Whilst the option to select either Lining figures or ‘Non-lining’/Old Style figures would be desirable, the Georgia typeface does not contain Lining figures. (Well, the version bundled with MacOS doesn’t, at least!)
Using FreeType as the back-end for glyph shaping and rendering doesn’t provide any additional support for OpenType features, because there is no support for those OpenType features in Qt’s API.
I have an experimental back-end idea which may be helpful, though it is sophisticated to the end-user.
In the latest public release of Dorico Pro 2, there are 3 types of frames: Music Frame, Text Frame, and Graphic Frame. Maybe one can set the text frame as LaTeX frame (using XeLaTeX). This frame won’t show what it looks like in the Dorico app but only show in compiled PDFs. Also, what filled in the Project / Flow information may be in LaTeX format (optional to user). Per each Dorico project file, there are user-fillable LaTeX preamble data which defines the specific location of font file used by LaTeX in this Dorico project (with their default OpenType feature settings).
Maybe other new ideas can be derived from what I guessed above. Maybe XeLaTeX can generate post-script data directly to Dorico for post-editing. As far as what I know at this moment, XeLaTeX compilation is not limited by Qt.
Interesting. I’ve actually had similar ideas before… but I think it’s important that a modern notation software supports modern font technology natively, not only for text but also for music fonts (the SMuFL specification contains interesting pointers to OpenType features). I wouldn’t want the developers to use their limited resources for such an adventurous stopgap…
Till now the only way is to manually compile wanted pages by using inDesign or LaTeX and overlap those compiled pages together to what compiled by Dorico.
Anyway, here are source codes of XeTeX and fontspec:
I would love (and have already written it) to be able to use XeLaTeX in text frames. That would be an amazing leap forward, as far as quality output is concerned (especially when dealing with complicated stuff, as columns, opera bouffe texts, foreign languages…)
True. And I’d sure love it too.
But despite its myriad of engraving rules and algorithms, Dorico is a WYSIWYG application. LaTeX doesn’t seem to fit at all into the concept, does it? My guess is that at some point we’ll have much more sophisticated layout features that will allow for high quality results without the need to export or compile the project to actually see them. Dedicating resources to implementing LaTeX support now would only postpone that. And, let’s face it, how many Dorico users can write LaTeX code? And even if they can, how many would actually jump through those hoops?
It would be a nice concept, but I think there is a danger of trying to invent a WISYWYG version of Lilypond-book. That was a great idea for combining complex text and music notation, but in practice the options for laying out the text and music “frames” were too limiting - in fact more limiting in some ways than the current state of Dorico.
Probably the best work flow that actually exists right now is to generate text as vector graphic images in Xelatex and import the graphics into Dorico. If Dorico had dynamic linking to external graphics files (in the same sense as “dynamic parts” and “dynamic cues”), that would pretty much do the job.
But having learned TeX on a 1980s vintage IBM PC with half a megabyte of memory (not several Gbytes), when processing a TeX file took about 1 minute elapsed time per page of output, I tend to stick with for “old-school” things like PDFLaTeX, not modern gizmos like XeLateX and LuaTeX
Fact is that despite XeLaTeX being an “old” thing, there’s no sophisticated WYSIWYG that gets close to it, especially when you need to typeset complicated things. I know it’s not the obvious way for Dorico, but I also know it would solve soooo many problems, in text formatting. And honestly, I thank myself to have had the curiosity to dive into LaTeX when I did : so much time earned and so many beautiful documents typeset. Once you work a dozen of hours to really understand how it works, it’s totally worth it. The net is filled with solutions to every problem you could have. It’s a dream, but it looks like a very reasonable one, on the user side.
The use of tokens in Dorico is not very far from LaTeX syntax. Or the html things we can add in these posts using the full editor. It’s really simple. All it takes is some time and some curiosity, and then you’ll wonder why it’s not compulsory to learn LaTeX in school (and get rid of MS Word and simile).
Talking about the compilation speed, my friend Clerk Ma is developing ApTeX (previously “pTeX-ng”) which has faster compiling speed than XeLaTeX. ApTeX is still under development: GitHub - clerkma/ptex-ng: Asiatic pTeX
I know musicians for whom any line of text with funny tokens or special characters in it is a rather frightening sight. You could probably call that a reason not to learn how…
On the other hand, most engravers are of a different kind, and used to scripting anyway, which is definitely more involved than basic LaTeX.
