Defining margins and kerning/protrusion in Luatex

If you are using LaTeX you need the package geometry to define the margin sizes, but what about LuaTeX?

Do we still need geometry or does it have its own commands to set the margins to the user's taste?

What about kerning and protrusion, is it better to use the package microtype or LuaTeX's own commands (*)?

(*) such as protrusionboundary, leftmarginkern, vkerning and so on.
(**) I'm creating a book.

• Note that you do not, strictly speaking, 'need' any of the packages to do anything. But you're not going to do it as easily as with (say) `\usepackage[margin=3cm, headheight=15pt, nomarginpar, bindingoffset=1cm]{geometry}` until you invest a lot of energy into creating your own set of page-settting macros.... Or are you asking are there (easy? already developed?) native-to-LuaTeX methods of achieving what `geometry` and `microtype` already do? – jon Nov 27 '16 at 1:00
• I'm asking if there are easy ways (single options) with LuaTeX to do the same or even better (for example kerning or spacing or protrusion), or if geometry o microtype are not good options because incompatibilities. – skan Nov 27 '16 at 3:18
• For example, I think you can change spacing with fontspec options, for example \defaultfontfeatures{LetterSpace=50} , but you could also use the microtype package. – skan Nov 27 '16 at 3:26
• No incompatibilities (though not every feature in `microtype` is available when using the LuaTeX engine). Perhaps some things are made easier, but your list of two packages aren't where the advantages are found. Note the subtitle to `microtype`: 'Subliminal refinements towards typographical perfection'. By its nature, the refinements are not meant to be easy to discern, so a lot of trial and error may be required for any given font (but once you've got your settings, you're good). If you just want letterspacing, you can load the same author's `letterspace.sty` ... or use `fontspec`'s features. – jon Nov 27 '16 at 5:21
• I usually use `microtype` because I have not invested the time into creating my own settings for the fonts I usually use using `fontspec`'s capabilities and because I feel like `microtype` offers more out of the box functionality. – jon Nov 27 '16 at 17:42

Margin setting depends to the document class and not to the engine. `geometry` or `typearea` (for KOMA-Script classes) are still needed. Using `microtype` for LuaLaTeX is no problem.

Forget fonts and page layout and all the rest of it. They don't matter at this point. It only makes sense to think about them later. Start by understanding what the content of a LaTeX document looks like. Learn what semantic or logical markup means and how to use it. Avoid appearance markup and you can defer most of the choices you are fretting about until you have the knowledge you need to make informed decisions.

You are confusing different things. Your question suggestions you are considering using LuaTeX instead of LaTeX, but that doesn't make sense. Besides, the rest of your question assumes LaTeX because the packages you mention are all LaTeX packages.

TeX itself provides primitives for formatting source code to produce a typeset document. It is an example of an engine. But we don't usually use TeX directly. Instead, we use a format which provides higher-level macros built on the primitives.

Formats include plain and LaTeX, but there are others. In addition, it is possible to load sets of additional macros or redefinitions of the format's macros, as well as defining or redefining them in the document. When we use the LaTeX format, the standard ways to do this include

``````\documentclass[]{}
``````

and

``````\usepackage[]{}
``````

The class sets the overall default format of the document and often adds additional macros and redefine existing ones. Packages alter the default format and/or add further macros and/or redefine existing ones.

All of this is loaded up and affects the processing of your document when you compile the source to produce the typeset output. You can do this with the TeX engine mentioned above. However, we now have additional engines to choose from. These include pdfTeX, XeTeX and LuaTeX.

So, you choose:

• an engine e.g. TeX or pdfTeX or XeTeX or LuaTeX, ...;
• a format e.g. plain or LaTeX, ...;
• additional sets of predefined/redefined macros e.g. a class, packages, ...;
• document-level options, additions etc.

The choice of an engine and a format are largely orthogonal to each other. You can choose plain and XeTeX or LaTeX and LuaTeX or plain and pdfTeX or LaTeX and TeX or LaTeX and pdfTeX or plain and LuaTeX or ....

However, if you choose LaTeX, then there is an additional consideration. A very small number of packages work only with particular engines, are fully supported only when using particular engines or require the addition of compatibility code when used with particular engines.

For example, `fontspec`, `polyglossia` and `unicode-math` work only with XeTeX and LuaTeX. `microtype` is fully supported only by pdfTeX, mostly supported by LuaTeX, partly supported by XeTeX and unsupported by TeX. `pstricks` is directly and fully supported by TeX and XeTeX, but requires compatibility code to work with pdfTeX because pdfTeX cannot use postscript images unless they are first converted to another format. In contrast, TeX cannot include anything but postscript images without conversion.

There is no magic formula because there is no best combination of the various elements which combine to format the document. The best combination is a function of the document and its author.

The differences between formats are much greater than those between engines in terms of their implications for writing the document. In most cases, it is relatively straightforward to switch from, say, pdfTeX to LuaTeX. In contrast, a document coded in plain would need very substantial rewriting to become a LaTeX document.

Since you are using LaTeX, therefore, you should just write a document in order to learn the basics. At this stage, it is irrelevant which engine you choose and you should not even consider which packages you might want until you need them. Indeed, until you have some knowledge and experience, you are not even in a position to select a class. So avoid class-specific code. Start with a standard class e.g. `book` and figure out the basics. Only at that point will it be possible to make a meaningful choice of class. Read the documentation for the class you choose, experiment and continue. Add packages only if you need them.