Here we explain about extending TEXDraw functionalities in depth.
The core components has similar properties.
||Text to display in $\LaTeX$|
||Initial text size in pixels, or world unit|
||Initial alignment to set, in code the value is in
||Display offset in pixels, or world unit|
||Inset padding in pixels, or world unit|
||Initial font color in RGBA
||Custom material to be rendered with|
||Overflow method to use, see enum values below|
||TEXDraw UI only, is it able to receive input events?|
||TEXDraw 3D only, for how much pixels ratio? 2 is double font resolution.|
||A C# code function to force draw update.|
||Hide text which excess
||Allow text that excess
||Scale down the rendering output.|
||Recursively set the size down until no text excess
The different between
BestFit can be noticeable.
DownScale is much quicker to render than
DownScale will simply scale down the resulting text so it will not respect available width.
If you want to constraint based on fixed height and width,
BestFit is better. To automatically adjust height based on width, leave it as
Hidden and set
ContentSizeFitter’s height fit to
Preferred Size. To automatically adjust width based on height, set it as
DownScale and set
ContentSizeFitter’s width fit to
Use this to make TEXDraw scrollable.
While you can also use ScrollRect, TexScroll has a performance benefit of only rendering what’s on the screen (using
Hidden overflow mode). You can’t do that with ScrollRect. TexScroll is suitable for rendering a very long $\TeX$ documents.
Use this to make TEXDraw links clickable and send unity code events.
To create a link you can use
href is the link target, and
text is the text to display. The link target string is sent together as the parameter of the firing
OnLinkClick event in
Internally you can get the resulting link rectangle area using
tex.orchestrator.rendererState.vertexLinks. Use this to code your own special behavior along with the link command. It really can do much more than just clicking links.
One of other implementation usage for links is you can embed it within a RectTransform. You can use TexEmbed to achieve this.
Use this to make TEXDraw receives input.
Currently it only act like usual Text Input, not having any special keys to handle special LaTeX input. Mind that when you want to use it.
Alternatively it’s probably easier for you and your users to have separate Text Input and then Usual TEXDraw as the preview.
TEXDraw included Open Sans by default as
\opens. You can set it as default text mode in TEXDraw preference.
The Open Sans is different than usual $\TeX$ fonts and will have fewer features. Because of that, Unicode conversion is turned off in that font.
TextMeshPro has crisp text rendering mode and it’s already built in Unity. TEXDraw can make use of TextMeshPro rendering capability so it’s looking crisp too.
TEXDraw can do this automatically for you, just find it in Menubar Tools > TEXDraw > Enable TMP Integration. You may see a rendering progress bar if you enable this for the first time.
If you see “You need to Extract TMP Essentials Asset First Before Activating TMP Integration” error, go to Window > TextMeshPro > Import TMP Essential Resources .
If you found “Requested build target group….” errors popped up, is a harmless error. You can safely ignore it.
You can disable TextMeshPro integration by go to the same menu when you enabled it before.
As for v5.7 there’s option to choose between dynamic and static mode. Dynamic mode is the preferred way as it may support more than just ASCII characters set for custom fonts. The old static mode is kept if for backward compatibility.
Back then when TEXDraw is in v4.x it has a robust RTL support to deal with arabic fonts. It’s dropped in 5.x so it’s not supported yet. You can ask me if you plan to use RTL in TEXDraw.
I think not a lot of people using NGUI nowadays so it’s no longer supported. The last version TEXDraw support NGUI was v4.4.1.
TEXDraw split the rendering into three parts:
Parsing: This is the process where string is converted into tokens we called
Atom. This atom itself doesn’t know any dimensions and only contain extracted data from text and the information about it’s current state it needed to render.
Boxing: This is the process where
Atomis converted into smaller subset of rendering blocks we called
Boxdefines each width and height dimension we know each box size up until the root box. Sometimes this process is repeated in order to satisfy layout requirements.
Rendering: This is the final process where all
Box-es are baked into a mesh buffer. All positions for each box are known and directly baked there. The final result will be a list of mesh buffers where each of them is sent to available rendering
GameObjectpool (hidden from editor) each with their own font texture.
TEXDraw is smart enough to invoke rendering where they need to. For instance, if you only change the color property of TEXDraw or hovering a link with TEXLink, only re-rendering happens. If you resize the RectTransform, only re-boxing and re-rendering happens. Full rendering only happens if the
text property has been changed.
Inside of any TEXDraw components, you can access a property called
orchestrator. It’s the internal factory of TEXDraw rendering engine, and it’s publicly accessible so you can extend it’s functionalities. Here are some properties inside
TexOrchestrator than you can use to extend TEXDraw functionalities:
||Internal text parsing engine. Note: This instance is shared across game lifetime.|
||Intermediary context state for parsing. Nothing useful here.|
||Intermediary context state for boxing. Nothing useful here.|
||Last cache after rendering. Contains some useful data about last rendering call.|
||Last cache after parsing. Contains tree-graph data about last parsing call.|
||Last cache after boxing. Contains tree-graph data about last boxing call.|
||WIdth and height of rendered text in local coordinate before getting modified by overflow policy.|
||C# code function for parsing. Output saved to
||C# code function for boxing. Output saved to
||C# code function for render. Output saved to
rendererState also contains some useful data to manipulate with.
||An array to
||A dictionary map from font ID to
||An array of tuple containing a string
||An array of tint color applied for each
||Effective clipping area (if overflow set to
Because TEXDraw often uses
\, you might want to use literal syntax in strings like:
texdraw.text = @"$\theta=\alpha^2+\beta^2$";
However for a long $\LaTeX$ it’s often better to write it in separate
.tex file in Resources and load it using
You can define
TEXDRAW_DEBUG in scripting definitions to enable debugging mode. Here are the things that you will unlock:
Debug Viewis visible in
TexConfigurationand if it activated all TEXDraw in scene will have a yellow-ish rectangle blob to give hints of invisible white spaces and other box area.
- TEXDraw child rendering components
TEXDraw3DRendererwill be visible in hierarchy.
- A tool will be unlocked in menu
Pool Checks. This editor tool helps to inspect any instance of memory leak in TEXDraw’s internal memory class pool.
TexModuleInitiator.cs. Obviously you need a moderate experience in extending someone else’s code. I may or may not help you doing this.
It’s already fast.
But for more reliable performance, you may want to put a dummy TEXDraw object in the first scene (even though it’s offscreen). This is because TEXDraw resouces is loaded “lazily”. If you enable/load TEXDraw in the middle of runtime for the first time, you probably will see a hiccup in a frame, albeit less than a second.
Also you may want to Enable TextMeshPro Support because it has better performance and more consistent rendering. The default dynamic font rendering Unity has a problem, that it’s generated runtime, so sometimes you’ll see a glitched display when using TEXDraw with it.
To reduce compile size generated from TEXDraw, you can remove unnecessary files from it. Here’s one of tips you can do:
- Delete unused fonts. Notably from
Extrasif you’re not using these fonts. (be cautions for
stmary, as these are symbol files you probably not aware of using it already)
- Delete unused font resources from
TEXDraw/Resources/TexFontMetadata. They’re not cleaned up automatically.
Due to technical challenges, there are few differences and limitations that need to be noted, especially if you already know to TeX works in different editor:
- TEXDraw don’t throw errors because of incomplete syntax. This can be tricky if you notice something that doesn’t work as expected.
- TEXDraw don’t support macro changes in runtime (for performance reason).
- TEXDraw don’t support
\usepackage. If you want a feature to be implemented please reach the developer or discuss it on forum.