D-Type Rendering Technology

Standard Suite

Text Suite

Power Suite

Apps & Tools

About D-Type

New in D-Type 8

PowerDoc Engine and Unicode Text Engine: Support For OpenType Color Glyph Layers

D-Type 8 supports OpenType fonts with color glyph layers. This is a Microsoft extension of the OpenType format which defines a special COLR table and a supplementary CPAL table in OpenType fonts. Microsoft uses this format for their color emoji fonts on Windows.

PowerDoc Engine and Unicode Text Engine: Support For OpenType Bitmap Glyph Images

D-Type 8 supports the OpenType sbix table with embedded PNG and/or JPEG images. This is the format that Apple uses for their color emoji fonts on macOS.

Text Layout Extension: Vertical Shaping API Exposed

Thanks to the underlying HarfBuzz 2 shaping engine, the Text Layout Extension that ships with D-Type 8 exposes an API for vertical writing. The existing lxLayoutApply and lxLayoutApplyPlus functions have been enhanced to provide two new text direction options: top-to-bottom (LX_DIRECTION_TTB) and bottom-to-top (LX_DIRECTION_BTT).

Also, our example_layout_extension example has been upgraded to show how to render both horizontal and vertical text. You can study, modify and/or use its source code, either in its original or modified form, as you see fit.

Frequently Asked Questions

Q1: Is D-Type 8 all about color emoji font support?

A: For the most part this is true. While in many use case scenarios, color glyphs/emojis are not that important, they still represent an interesting extension of the OpenType font format. It's a feature that some of our customers asked for and we decided to support. But because there are so many different and even competing ways that color glyphs can be implemented in OpenType (as bitmap images, color glyph layers and even SVG documents), we didn't want this support to be an afterthought. We wanted to support it right.

At the same time, there are many other important enhancements under the hood in D-Type 8. For example, D-Type's Ultra-Fast Grayscale Rasterizer and Ultra-Fast RGBA Rasterizer now provide support for parallel rasterization (making it possible for many threads to rasterize the same vector description at the same time on multi-core machines!) while their already high output quality has been improved slightly. Also, D-Type Text Layout Extension now exposes an API for vertical writing.

Q2: What do I need to render OpenType Color Glyph Layers and Bitmap Glyph Images?

A: You need D-Type PowerDoc Engine or D-Type Unicode Text Engine and, additionally, our new D-Type External Format Plugin.

Q3: What do I need to render OpenType Bitmap Glyph Images only?

A: You still need D-Type PowerDoc Engine or D-Type Unicode Text Engine and, additionally, our new D-Type External Format Plugin.

Q4: What do I need to render OpenType Color Glyph Layers only?

A: In this case you only need D-Type PowerDoc Engine or D-Type Unicode Text Engine.

Q5: Why is D-Type External Format Plugin necessary?

A: D-Type External Format Plugin provides support for external graphics formats, such as PNG and JPEG. Support for PNG and JPEG formats is not available in D-Type Font Engine or D-Type PowerDoc Engine. In the future, D-Type External Format Plugin will be updated to provide support for other required external graphics formats, such as SVG or TIFF. Support for these external formats will always be provided outside of core D-Type Engines.

Q6: Can I use D-Type External Format Plugin with D-Type Font Engine?

A: Technically, yes, however this is of limited use and not recommended. In this use case scenario D-Type External Format Plugin will only help you decode PNG and JPEG images. All additional work associated with displaying color glyph images still needs to be done by you. Please note that D-Type External Format Plugin is first and foremost an extension for D-Type PowerDoc Engine and D-Type Unicode Text Engine.

Q7: How do I use D-Type External Format Plugin with D-Type PowerDoc Engine and/or D-Type Unicode Text Engine?

If D-Type External Format Plugin is used in conjunction with D-Type PowerDoc Engine and/or D-Type Unicode Text Engine, you never have to access it directly. Simply add it to your source project, let D-Type Engine use it, and forget it.

Q8: What about SVG support in OpenType?

A: Support for SVG glyphs is currently not available but is being considered for the next major D-Type release. Thanks to D-Type External Format Plugin, we believe that SVG support will be much easier to provide in the future. Keep in mind that OpenType is an evolving format and its specifications keep growing. As with previous major extensions of the OpenType format, our goal is to support any OpenType features and capabilities that are worthy of adding to D-Type.

Q9: Currently I use D-Type Power Engine? Do I need any other D-Type engine or extension?

A: If you only want to support OpenType Color Glyph Layers, you don't need any other D-Type engine or extension. If, however, you also want to support OpenType Bitmap Glyph Images, then you will need to purchase D-Type External Format Plugin. You can purchase this extension using our Purchase Form.

Q10: Currently I use D-Type Unicode Text Engine? Do I need any other D-Type engine or extension?

A: The answer to this questions is exactly the same as to the question Q9 above.

Q11: Currently I only use D-Type Font Engine. What should I do?

A: Using D-Type Font Engine you will be able to get raw data describing color glyph layers and bitmap glyph images. There is a new API function for this. However, unless you upgrade to D-Type PowerDoc Engine or D-Type Unicode Text Engine and additionally purchase our D-Type External Format Plugin, you will need to render these glyphs yourself.

Q12: Is it difficult to render color bitmap glyph images myself using only D-Type External Format Plugin and D-Type Font Engine?

A: It's not easy. You need to decode PNG and JPEG images, scale them to the specified size and blend with your background. On top of this, you probably want to implement some sort of caching, as extracting and rendering RGB(A) bitmap images can be a resource intensive task. Also, if you need your output to work properly when skewed, rotated or transformed using an arbitrary affine and/or perspective transformation matrix, such as in the following illustrations, be prepared for some extra work. Thus, if you haven't done already, we strongly suggest that you upgrade to D-Type PowerDoc Engine and purchase D-Type External Format Plugin.

Q13: Is it difficult to render color glyph layers myself using only D-Type Font Engine?

A. This is not too hard, as you don't need to read, decode and render any bitmap images. However, you still need to process raw data describing color glyph layers and render these layers yourself. You probably want to implement some sort of caching if rendering speed is important.

Q14: Couldn't you add full support for glyph layers and bitmap glyph images to D-Type Font Engine?

A: Doing this would turn D-Type Font Engine into a mini D-Type PowerDoc Engine. Large portions of D-Type PowerDoc Engine code would then end up in D-Type Font Engine. It doesn't make sense to do this from a technical standpoint. Also, bear in mind that D-Type PowerDoc Engine supported its own colored glyphs (called PowerGlyphs) since the early 2000, i.e. long before colored glyph support was available in OpenType. Having support for colored glyphs in two different engines also doesn't make a lot of sense from a design standpoint.

Q15: Why is all this rendering machinery necessary to support color glyph layers and/or bitmap glyph images?

A: This question should be directed to the developers and maintainers of the OpenType font format.

Q16: Is D-Type's support for OpenType Color Glyph Layers and Bitmap Glyph Images equally available on all platforms (Windows, macOS, Linux)?

A: Of course. This is how D-Type has been designed since its inception.

Q17: What do I need to support vertical text using D-Type Text Layout Extension?

A: You can now support vertical text yourself using only D-Type Font Engine and D-Type Text Layout Extension. Simply call the existing lxLayoutApply or lxLayoutApplyPlus function and pass it your Unicode text along with one of the two new text direction options: top-to-bottom (LX_DIRECTION_TTB) or bottom-to-top (LX_DIRECTION_BTT). As before, you will get back an array of glyphs to display in the correct visual order along with the coordinates necessary to properly position those glyphs. The only difference is that the glyphs in this array will be positioned vertically. This means that their x coordinates will be more or less uniform, while the y coordinates will be in an increasing (or decreasing) order, depending on the specified text direction option.

However, using our PowerDoc Engine or Unicode Text Engine is still the most advanced method of rendering vertical text, since it provides features and possibilities that are not provided by the Text Layout Extension on its own (e.g. automatic bidirectional reordering or rotation for non-vertical scripts, different types of baseline alignment options etc).

Q18: Do I get support with all these new D-Type 8 features?

A: If you have an existing active support contract, yes, you will continue to receive support. Otherwise, if you need assistance, you should purchase one of the available technical support options.

Q19: Since Apple is planning to release an ARM based Mac computer, will D-Type 8 be available on Apple's new platform? Will you offer an ARM build together with Intel?

Yes, D-Type 8 will definitely be available for ARM based Mac computers. We can't wait to see D-Type running on yet another platform and experience the performance and energy improvements that Apple is promising. As soon as we have the libraries for this platform ready, we will release them and make an announcement on our web site. Our initial thinking is that these should be two separate libraries, not one universal library (for ARM and Intel), due to the following considerations:

  1. Technically speaking ARM and Intel are two very different CPU architectures. By packaging the two libraries together we will create needles dependencies that will only make it more difficult for us to release fixes or patches in the future. For example, a compiler bug in the library for one architecture would require us to rebuild the library for the other architecture as well.
  2. Packaging the libraries together will make more work for us in the future, when Apple decides to stop supporting Intel. It is wiser in our opinion to keep them separate from the beginning.
  3. Users who really want to create a universal library can do this themselves using the lipo command line utility. See, for example, this article on stackoverflow.com.

More Information

If you have a question that is not answered on this page, use our Obtain Additional Information form. We will post your question and our response to this page within a few days.