TRichView.com

New versions are released: TRichView 16, RichViewActions 6, ScaleRichView 7

Trial versions are available here:
http://www.trichview.com/download/

Changes since the last public update:

TRichView:
- use of Uniscribe instead of WinAPI to render bi-directional text and exotic scripts better
- "justify" alignment and character spacing are supported for bi-directional text
- new type of alignment: "distribute" (aligning text to the both sides by adding space between all characters)
- customized alignment of the last line for justified and distributed paragraphs
- option to store StyleTemplates outside of RVF files
- opacity property for backgrounds of paragraphs, tables, cells, text boxes and sidenotes
- much more efficient text formatting for justified paragraphs and very long text items
- options for supporting vertical text in table cells

ScaleRichView
- support for all new features of TRichView 16 (Uniscribe, semitransparent background, etc.)
- support for printing transparent images; support for transparency in gif animations
- line numbers

RichViewActions
- "default" checkbox on the item properties dialog, to allow defining properties for new tables and horizontal lines
- support for new paragraph options (distributed alignment, last line of justified and distributed paragraphs)
- support for opacity of backgrounds
- new action to insert "page count" field
- option to disable "Save" button for unmodified documents
- the second set of toolbar images

All components:
- support for Delphi and C++Builder 10 Seattle
- help file integration in RAD Studio (for XE8 and 10 Seattle)
- changes to support high DPI display modes

---
If you like this update - there are +1 and like buttons at the top right side of the page
---

Complete list of changes

• TRichView
• RichViewActions
• ScaleRichView

Previous versions
http://www.trichview.com/forums/viewtopic.php?t=6885

Uniscribe

Before this version, our components processed text using functions from Windows API.
Unfortunately, Windows functions for processing bidirectional (left-to-right and right-to-left) text are very unreliable: for the same text, they could give correct results for one font, and completely incorrect results for another font.
So our components implemented two different set of text processing functions: with and without support of bidirectional text.
Bidi-support was turned on by assigning rvbdLeftToRight or rvbdRightToLeft to BiDiMode property.

Since this version, our components use Uniscribe library.
If Uniscribe is not found, the components fall back to Windows API, but this situation unlikely happens: Uniscribe is included since Windows 2000 and Internet Explorer 5.

Previously, if support of bidirectional text was turned off, Arabic and Hebrew text were processed completely incorrectly. Now, with Uniscribe, even with BiDiMode=rvbdUnspecified, text is processed correctly (but the proper arrangement of different items on lines is still enabled only in rvbdLeftToRight or rvbdRightToLeft modes).

Uniscribe draws text using glyph indexes in font instead of character codes. This causes problems with recording drawing output to metafiles, if this metafile will be displayed on a different computer, or, for example, used by PDF generation.
To solve this problem, we implemented a special metafile-friendly drawing mode. In this mode, character positions are calculated using Uniscribe, but drawn using standard Windows functions. This mode is used by TRVPrint and TRVReportHelper components if you assign True to their MetafileCompatibility property.

You can switch a text engine back to Windows API. It is not recommended, but some reasons for this are possible:
- if bidi-support is turned off, Windows API is faster
- you want your old document to be displayed exactly like it was before.

All our ActionTest demo project now have this options window:

This dialog is shown by "Tools | Options" command.


Our components use Uniscribe only on the basic level: to draw and measure text, to calculate coordinates and caret positions. Line breaking and item arrangement on lines is still performed using our own procedures.

Information about Uniscribe:
https://en.wikipedia.org/wiki/Uniscribe (ignore the statement about DirectWrite - both Uniscribe and DirectWrite have their own strong sides)
https://msdn.microsoft.com/ru-ru/librar ... s.85).aspx (copy the whole link to the browser's address bar)

Improved processing of bidirectional text

In previous versions of our component, when support of bidirectional text was turned on, some features were disabled:
- "justify" alignment worked like left alignment
- custom inter-character spacing was ignored
- a special algorithm helping TRVPrintPreview to scale text more precisely was not run.

Since this version, all these features are implemented for bidirectional text, both for Uniscribe and for Windows API.

We completely rewrote our implementation of justified paragraphs. In addition to support of bidirectional text, the components format them much faster and use less memory for their processing.

Distributed paragraphs

In addition to left-aligned, right-aligned, centered and justified paragraphs, we implemented a new alignment type: "distribute".

In justified paragraphs, text is aligned to both left and right sides by adding space between words. This alignment type is useful for Western text.
However, East Asian scripts (like Chinese, Japanese, Korean) do not use space characters to separate words, so this type of alignment is useless for them.
Distributed paragraphs add space between all characters:


This alignment type can also be useful for Arabic texts, and for achieving decorative effects in Western texts.

RichViewActions support this new alignment type:
- new TrvActionAlignDistribute switches the current paragraph alignment to "distribute"
- "distribute" is added to the paragraph dialog:


Last line alignment

Since this version, the components allow to specify alignment of the last line of justified and distributed paragraphs. If a paragraph has a single line, this alignment is applied as well.
Possible options:
- auto (left for left-to-right paragraphs, and vice versa)
- left
- right
- center
- both (the same as other lines).

RichViewActions allow changing this alignment in the paragraph options dialog.
Also, TrvActionAlignDistribute and TrvActionAlignJustify apply the value specified in their property. The default values correspond to MS Word's settings:
- "auto" for justified paragraphs
- "both" for distributed paragraphs.

Vertical Text

Traditionally, many East Asian scripts are written vertically, from top to bottom. In TRichView, you can rotate text by 90° clockwise to provide a top-to-bottom text flow.

Support for Chinese, Japanese, Korean (text flow: top to bottom, columns are arranged from right to left)

To keep character orientation, one can use vertical fonts (containing characters rotated by 90° counterclockwise). Windows includes several vertical fonts having names prefixed with “@”, for example “@Arial Unicode MS”, “@Batang”, etc. In TRichView, table cells have an option to apply such fonts automatically to text rotated vertically.

Of course, instead of using this option, you can directly specify a vertical font for text. However, fonts having names started from “@” are hidden from user interface of RichViewActions, or from TFontDialog.

Support for traditional Mongolian (text flow: top to bottom, columns are arranged from left to right)

In TRichView, table cells have an option to reverse a line order. For vertical text, it means reversing a column order. For example, for text rotated by 90° clockwise, this options arranges columns from left to right.

Background opacity

In this version, we implemented a custom degree of transparency for backgrounds of the following objects:
- paragraphs
- tables
- table cells
- text boxes and sidenotes.

A new property Opacity is added to these objects. It defines opacity in 1/1000 of percent. Physically, there are only 256 gradations of opacity/transparency, so this scale is obviously redundant. It was chosen for the convenience of specifying opacity in fractions of percent.



It was not too difficult to implement background transparency on the screen. Implementing printing was much more complicated, because the most of printers do not support opacity.
Our components solve this problem in the same way as printing transparent pictures: transparent areas are drawn into bitmap, then this bitmap is printed.



Limitation of TRVPrint (ScaleRichView does not have these limitations):
- TRVPrint does not completely support transparency in rotated objects (i.e. objects inserted in rotated cells); you can see plain color areas through such objects, but not textured or semitransparent background
- you can see page background through semitransparent areas of text boxes, but cannot see other (overlapping) text boxes or the main document
- you cannot see text boxes through semitransparent areas of the main document.



Limitation of ScaleRichView:
- bitmaps created to print semitransparent areas are rendered in 96 dpi; so, if you can see a text fragment in such areas, it looks rough comparing to surrounding text, when printing on high-resolution printers.

A new property is added to TRVReportHelper - AllowTransparentDrawing: Boolean. It is taken into account when drawing on the screen.
If False, the component draws semitransparent areas (of pictures or backgrounds) in a temporal bitmap, then draws this bitmap.
If True, it draws transparently directly on the canvas. It is recommended for drawing on bitmaps or on the screen. It's ok for drawing in metafiles, for documents not containing TPngImage images (transparent backgrounds, TGifImage, TIcon are ok in metafiles).

User interface

RichViewActions are updated: opacity is added to color pickers (when appropriate), paragraph border and fill color dialogs.



Printing transparent pictures in ScaleRichView

Before this version, transparency in pictures was supported by ScaleRichView only on the screen, not on printers. Since this version, all kinds of transparency (both in background and in pictures) is supported in ScaleRichView

Storing StyleTemplates outside of RVF files

StyleTemplates in our components are similar to Microsoft Word styles (so, in this text, I will use "StyleTemplates" and "styles" as synonyms).
They define both text and paragraph attributes, may define all possible attributes or only a subset of them, may be applied to text and to paragraphs, may have a parent style (to inherit properties from).

RichViewActions include commands for managing, importing and exporting styles.


Normally, StyleTemplates are stored inside documents (in RVF format, but can also be stored in RTF and DocX).

In this version, we implemented an option to store them outside of RVF files.
More exactly, you could save StyleTemplates in external files even in older versions, but this function was used for export of styles, or for specifying a default set of styles for new documents.
In this version we added a new option in RVFOptions property: rvfoSaveStyleTemplatesOnlyNames. If included, the components store in RVF files not the whole collections of styles, but only names of styles and information allowing to distinguish character and paragraph properties having values inherited from styles and properties defined on top of styles.
So, styles can be stored externally, and will be applied to loaded RVF documents automatically.

This option is useful for implementing multiple documents using the same collection of styles, for example dictionary articles or help topics.

High-DPI display modes

High density displays are becoming increasingly popular, particularly in mobile devices.
In Windows, 96 dpi is counted as 100%. High DPI devices may have density 150%, 200%, or even more.
In combination with small sizes of mobile devices, high pixel density makes non-DPI aware applications almost unusable, because if sizes of objects are defined in pixels, they become too small.

By default, Windows do not allow applications to run in high-dpi mode. It draws their windows in 100% dpi mode, then stretch-draws them on the screen. After that, objects have proper sizes, but everything looks blurred and not nice.
You can allow your applications to run in high-dpi mode by specifying it in their manifests. For older versions of RAD Studio, you need to provide a custom manifest. In RAD Studio 10 Seattle, there is an option for high-DPI in the project options.

High dpi does not cause problems for the most objects in Delphi applications, because Delphi scales all sizes and fonts according to the screen resolution automatically.
However, we had to make changes to adjust sizes of several objects proportionally to dpi, including:
- touch screen selection handles,
- color picker windows and color grids in RichViewActions,
- table size popup window in RichViewActions,
- heights of items in the combobox of styles in RichViewActions,
- images in dialogs of RichViewActions (only integral multiple to avoid distortion).

Also, since this versions, sizes of list marker text are stored in DFM and RVF in a dpi-independent way.

Changes in RichViewActions UI

In addition to changes related to new features (distributed alignment, last line alignment, background opacity, vertical fonts in a table cell, reverse line order in a table cell), RichViewActions include the following changes:

- "default" checkbox in the property dialogs for tables and horizontal lines; if the user checks it, the specified values of properties will be applied not only to the current table/line, but to all new tables/lines.


- new TrvActionSave.DisableWhenUnmodified property. If it is set to True, "Save" command is disabled until a document is modified.

- new TrvActionInsertPageCount action to insert "page count" field; "page count" and "page number" fields were introduced in TRichView 15, but until now RichViewActions included only a command for inserting "page number".

RAD Studio integration

Since this version, our help files are integrated in RAD Studio IDE.
It became possible in RAD Studio XE8 and RAD Studio 10 Seattle, because they use a standard CHM help format.

1) You can press F1 in the code editor or the Object Inspector to get help about a type, a class or a property.

2) Our help files are accessible from RAD Studio menu "Help | Third-Party Help"

Line numbers in ScaleRichView

TSRichViewEdit has a new property: LineNumberProperty.
Subproperties:
- Visible - hides/shows line numbers
- StartFrom - starting value
- Step - only every Step-th line number is shown (others are not shown or drawn as ticks)
- Font
- DistanceFromText
- TablesAsLines - if True, tables are counted as lines, so the result is compatible with TSRichViewEdit.GetCurrentLineCol; if False, tables are not counted (like in MS Word). Since, unlike MS Word, ScaleRichView allows positioning the caret before and after tables, it's natural to count them as lines
- Ticks - if True, the component draws ticks and a vertical line

A new action TsrvActionLineNumbers shows/hides line numbers.

Line numbers are shown on the left margin (or on the right margin, if BiDiMode=rvbdRightToLeft).
They are visible not only on the screen, they are printed as well.

Default line numbers:


Step=5


Step=10, Ticks=True

We uploaded an update: TRichView 16.0.1, RichViewActions 6.0.1, ScaleRichView 7.0.2

This is a maintenance release (fixes and tweaks)

We updated exe-demos for PDF generations using thirdparty tools:
- eDocEngine http://www.gnostice.com
- LLPDFLib http://www.sybrex.com

The main change in these demos is assigning True to MetafileCompatibility property of TRVReportHelper components.
For eDocEngine, this assignment is made by TgtRichViewInterface class itself, if you use new version of eDocEngine.

The compiled demos are here: http://www.trichview.com/download/demo.html