# prevent combining characters if single characters are available [closed]

I am working a lot with characters such as:

ā ū ī š ṣ ḫ ḥ ǧ ġ ṯ ṭ ẓ ḍ ḏ.

There are (at least) two ways to typeset such characters

1. either as a single character or
2. as a combined character.

Take ā as an example. Either (#1) ā is set as the unicode character U+0101 (LATIN SMALL LETTER A WITH MACRON) or (#2) it is set as a combination of U+0061 (LATIN SMALL LETTER A) and U+0304 (COMBINING MACRON)

How can I force LuaLaTeX to use method #1 instead of method #2? Method #2 seems to be the default even though my source text contains the single character "ā" (U+0101)? My font does contain "ā" as a single character (U+0101) just as it contains all other characters I need as single characters. I don't want LaTeX to create these characters through combination.

MWE:

%!TEX TS-program = lualatex
\documentclass{scrartcl}

\usepackage{fontspec}
\setmainfont{Times New Roman}

\begin{document}
ā a
\end{document}


## closed as off-topic by Andrew Swann, egreg, Stefan Kottwitz♦Nov 1 '16 at 10:41

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "This question does not fall within the scope of TeX, LaTeX or related typesetting systems as defined in the help center." – Andrew Swann, egreg
If this question can be reworded to fit the rules in the help center, please edit the question.

• How do you know they are typeset as a combination? It seems to me that does what you want compiling your code. – karlkoeller Jan 10 '15 at 6:02
• This is not a luatex problem. Mac OS uses the "decomposed" form of umlauts in the file system and some/many/all (I have windows and so don't know the extend of the problem) copy&pasting actively replace composed chars by the decomposed form. See also developer.apple.com/library/mac/qa/qa1235/_index.html. If your input contains decomposed chars you could (with a feature file) force luatex to create a pdf with composed chars but copy & pasting from this pdf could change the chars again. – Ulrike Fischer Jan 10 '15 at 10:55
• I agree that this is somehow off-topic (because the issue is not with TeX), but a nice answer (by @Ulrike?) explaining the problem would carry a lot of value I think. It would be sufficient to just repost the comment as an answer ;) – yo' Jan 12 '15 at 13:00
• If I copy the output and paste it in rishida.net/tools/conversion I get, in the “Hex code input” box, 0101; if I paste it in other applications I get 0061 0304. So it depends on the application where you paste. Note: using Mac OS X 10.9 – egreg Jan 12 '15 at 13:41
• @UlrikeFischer : Let me rephrase the question and then you can post your comment as an answer, alright? – ClintEastwood Jan 13 '15 at 22:51