\documentclass[english]{elsarticle}
\usepackage{babel}
\begin{document}
%\def\appendixname{Appendix }%from elsarticle.cls
\appendix
\section{Title of Appendix A here}
\section{Title of Appenid B here}
\end{document}
@DavidCarlisle I'm wondering if I should combine all (most?) of the Unicode loaders in to one file. I see Chris's point about separate ideas but I'm not sure anyone will use them like that: probably all or nothing.
Specifically for the arrows, you can use the decorations.markings library with, if desired, arrows.meta for enhanced tip options.
These can be added as single markings or in stepwise fashion. You can measure in absolute units (e.g. 5mm) or as a fraction of path length (e.g. 0.5) and from the sta...
That compiled just fine (?!)
Sorry, I'm talking about the answer that does not just implement the arrowheads, but also the colored segment.
The error I get when compiling in my larger document is in a part that is seemingly unrelated. However, if I remove the solution to my question the document compiles just fine.
What could possibly be going wrong? I'm embedding the solution into a "larger" tikzpicture but that picture compiles just fine, separately.
Okay, I've made some progress: Eliminating the part where the supposed error occurs also cures my problem.
Could it really be that I've made some error in part of my code which doesn't give any problems when compiling as long as I don't insert a certain piece of code into my tikzpicture, but then suddenly gives problems?!
The error I'm getting is in a list that occurs later on: The error message is "Lonely \item---perhaps a missing list environment" (this is not the case)
The compiled pdf does indeed have problems with the list
Is it possible that list environments + certain tikz things somehow interfere with each other's workings?
Ohhhh... there is something involving "list" in the solution!!!
@JosephWright I should think having it all in one file and setting up all the defaults in one file is file, especially of more or less same loader code could then be used by packages to re-input unicodedata.txt to pick up new settings if needed
@Danu there is a reason that latex uses \newcommand that warns the user if they are about to break the system, rather than \def which silently does whatever it's asked:-)
@EllaJay I tried, but the JPG is included correctly. This is what I get from identify: XSlice1.jpg JPEG 773x786 773x786+0+0 8-bit sRGB 131KB 0.000u 0:00.000
@DavidCarlisle I stumbled across Blocks.txt, which is a handy reference for the different Unicode blocks (surprising!). However, while it's used by ucharclasses I don't think it's ideal for the basic set up: there's no differentiation on character meaning within a class.
@DavidCarlisle (Indeed, one can see that really a wrapper is needed around \XeTeXcharclass to allow for the fact that different 'views' of code points need different divisions)
@JosephWright yes I use blocks.txt as an input into unicode.xml it's a pretty course categorisation though.
@JosephWright but could be like the catcodetable stack handling where we left the code in the format as pretty basic and put a higher level interface to swapping it in and out into a package...
@DavidCarlisle Question really is whether the current data is useful: I think from Qing Lee's comment it's certainly handy for the CJK package authors (though in an L3 context I'm minded to say we'll over-write it entirely)
@egreg Yes, I will return for sure! Next week I don't know (as I did my job already well) but next year I'll be in Venezia again from time to time, until April
@egreg Steampunk here. In the midst of thousands of tons of pure metal, cutting, welding, in claustrophobic corridors full of wires lines for energy, light, welding, I build a redundant 10G fiber and WiFi network.
@StefanKottwitz Well, some decades ago it would have been the only way. ;-) I seem to remember there's a description of a long gondola trip in “Der Tod in Venedig”.