TRichView.com

Hello,
I'am currently looking for a component to replace our Word based printing system. We have a lot of old templates based on RTF files containing many tables and fields.
After migration the output on printer or PDF should be close to the word. In my first tests I saw some glitches after import the rtf into TRichView / TSRichViewEdit - several table rows become higher than in word - because it contains a formulas? - which needs more space than the cell width.
Is there an Option to disable that cell autosizing?

- missing cell borders in some cases?

- the cells have a grey background - in Word the whole table gets that background - in RichView there are thin white lines between the cells

- can we find the formulas in the internal object modell of richview - to evaluate / replace them with the current values from our datastore?

-- Why isn't it possible to attach / link a screenshot of the problem? Left - is Word generated PDF -- Right is TRichtEdit - print to PDF - there are also problems with spacing inside table cells -
the RTF used to produce this will I sent by mail.

André

Attachments are allowed, including screenshot ("Attachment" tab below the message editor), but I received a screenshot with your email.
To answer your questions, I need a sample RTF to reproduce them, because each problem needs to be checked separately.

1) In MS Word, table rows may have heights defined either "exactly #", or "at least #'. Unfortunately, the current version of TRichView supports only "at least" model, so height of rows cannot be less than their content. More exactly, in TRichView, this option can be set only to the whole table, by including rvtoIgnoreContentHeight in table.Options. In the next update, I'll add this option in each cell, with the proper import and export to RTF and other formats.
2) I cannot reproduce missing cell borders in the newest version of TRichView, so I believe it is fixed.
3) White lines between the cells occur because, unlike MS Word, TRichView does not draw cell background in place of hidden border sides. This behavior can be changed by including rvtoCellBelowBorders in table.Options. However, in the current implementation, in this table this option may lead to disappearing of some cell borders. It will be fixed in the next update.
(
If you want to change table options for all tables that added in TRichView, you can process OnItemAction event: )
4) TRichView loads your fields as a plain text, so you need to check all text and replace fields to values.
There is a separate add-on doing this work (ReportWorkshop), but it uses its own field syntax, so, if you have many existing templates, it's better to do this field replacement yourself.
The demos that replace field codes to values are here: https://www.trichview.com/forums/viewtopic.php?t=8
Choose the most appropriate demo, probably it is MailMerge-Text3.
It uses '{}' instead of '[]', but more important, it does not support nested fields, so you need to change parsing logic.

1) thank your for explaining me - why this happens - and that you plan to improve it (I'am no expert at this level of RTF)

2) Ok - I will try to get the current demo version to run - instead of the GetIt version - to give you proper feedback if it is really fixed or not

3) the fix with the OnItemAction handler is working for me - it now looks much closer to the original PDF - as I understand if you implement
the change from point (1) - I do no longer need to add [rvtoIgnoreContentHeight] to the table options?

4) I will look into that sample - and how I can make it useable for me.
(Our fields also contain small scriping parts behind the [scr] with SQL selects and so on -- is this information kept somewhere in
your document object modell?)

One more - I implemented a Simple PDF Output into the ActionTestUni Sample - using the current SynPDF components, there are some small differences between that what I see on the screen and the PDF - is this a synPDF problem?
on screen - in pdf - Is it possible that on screen / editing doesn't show the grey lines from the tables?
in PDF lines are longer than required? rounding bug?

André

My PDF Code - copied in parts from the forum -

3) Yes, with new properties, rvtoIgnoreContentHeight will not be needed for such documents.

On the screen, grid lines are shown in place of zero-width borders or hidden border sides (to help editing).
They can be turned on/off by including/excluding rvoShowGridLines from RichViewEdit.Options and repainting (calling RichViewEdit.Invalidate).
They can be customized using properties of TRVStyle: GridColor, GridReadOnlyColor, GridStyle, GridReadOnlyStyle.

Most probably, the line ending problems happen because GDI lines do not include the ending pixel, while in PDF it is displayed. I am not sure if other PDF generation tools have the same problem, probably yes. I'll try to see what I can do.

As for formula field. Unfortunately, loading these fields from RTF is not supported, only field values are loaded as a visible text.
Well, it would not be too difficult to add an event that will be called when reading RTF. In this event, you will have input parameters:
- visible text
- field code (that will contain your SQL codes)
Output parameters:
- visible text
- item tag (invisible text associated with each item; for hyperlinks, it is usually used for storing targets; for other content you can use it as you want).
A similar thing is implemented for RTF merge fields (see OnReadMergeField event).
The main problem: it will be hard to store this information back to RTF as formula fields again. So you will need either to modify visible text on loading to include all information in it, or use native TRichView format RVF (because item tags for can be stored only in this format).

Hi,
ok - that with screen gridlines works - one step closer to the original.
There are so much properties its not easy to find the right one for each case - It seems that there is nearly for every case a property?

Most probably, the line ending problems happen because GDI lines do not include the ending pixel, while in PDF it is displayed. I am not sure if other PDF generation tools have the same problem, probably yes. I'll try to see what I can do.

Ok I understand the method ActiveEditor.DrawPage gets only the VCL TCanvas - and doesn't know anything - that this is an PDF - and your code draw every line "one pixel" longer than required to avoid the GDI logic of the missing last pixel - but the PDF Canvas draws also the last pixel to the output?
- so I may add an new Property to SynPDF - that VCLCanvas routines - should not draw to the last pixel if painting lines?
Does your code know if lines are connected? or creating a closed object? (rectangle, polygon?) - that would also fix some smaller effects on corners, especially if lines gets thicker than one pixel.

As for formula field. Unfortunately, loading these fields from RTF is not supported, only field values are loaded as a visible text.

That will become a problem - with our current design - so we will need to discuss this in my developer group. If we can live with this - or need a solution.

Well, it would not be too difficult to add an event that will be called when reading RTF. In this event, you will have input parameters:
- visible text
- field code (that will contain your SQL codes)
Output parameters:
- visible text
- item tag (invisible text associated with each item; for hyperlinks, it is usually used for storing targets; for other content you can use it as you want).

Ok - that may be a solution for the printing / output - but not the editing of the templates - which is also done by our customers, for this we will still need Word in that case. In our case fields are not only replacement values - we have also special field expression - which we expand to new sub tables inplace - based on SQL/Scripting expressions.

A similar thing is implemented for RTF merge fields (see OnReadMergeField event).
The main problem: it will be hard to store this information back to RTF as formula fields again. So you will need either to modify visible text on loading to include all information in it, or use native TRichView format RVF (because item tags for can be stored only in this format).

the use of a proprietary file format - is currently no real option for us. But we will discuss this - and if we decide to license your library - may be we can ask / talk again of finding a solution to store fields in complete back to rtf / docx?

Thank you very much for your quick responses here thats nice and makes a good impression. Are you the only active developer of this library or are there more people behind?

André

All these technical problems are solvable.

But as for the changes that will benefit many users (such as supporting "height exactly equal" option for cells, line ending pixel problems, fixing cell-below-border drawing), I'll implement them in the next update in any case.
More special features, such as support of formula fields (both for reading and writing), can be implemented if your sponsor them.
Also, I can do a custom work to help integrating TRichView in your application, with per hour payment of any other payment option if you need it.

PS: in this table, some borders look like squares/rectangles, but they are actually not. I checked one of "T-in a square" cell borders. It has a hidden right border side, but the cell to the right has a visible left border side, so it looks like a closed square, but it cannot be drawn as a rectangle.

But as for the changes that will benefit many users (such as supporting "height exactly equal" option for cells, line ending pixel problems, fixing cell-below-border drawing), I'll implement them in the next update in any case.

Ok - thats great.

More special features, such as support of formula fields (both for reading and writing), can be implemented if your sponsor them.
Also, I can do a custom work to help integrating TRichView in your application, with per hour payment of any other payment option if you need it.

I will take this info to our meeting... I see this as point for you and your product.

PS: in this table, some borders look like squares/rectangles, but they are actually not. I checked one of "T-in a square" cell borders. It has a hidden right border side, but the cell to the right has a visible left border side, so it looks like a closed square, but it cannot be drawn as a rectangle.

Thats true the layout with tables and merged cells can't have perfekt borders - so that will need some kind of AI to find borderlines, which can connected to one polyline and so don't have lost pixels on the corners.

I checked one of "T-in a square" cell borders. It has a hidden right border side, but the cell to the right has a visible left border side, so it looks like a closed square, but it cannot be drawn as a rectangle.

If I understand this right - its our task to simplify the borders, instead mixing borders from left and right - cell - just make a border around the left cell so thats a true rectangle - that will solve / improve it?

1) I've implemented "Exact height" option for cells (as new Cell.IgnoreContentHeight: Boolean property).
It can be saved and loaded in RVF, RTF and DocX formats.
RichViewActions dialog is modified:


2)

If I understand this right - its our task to simplify the borders, instead mixing borders from left and right - cell - just make a border around the left cell so thats a true rectangle - that will solve / improve it?

I am afraid it would not be easy to do this work manually.
No, I'll try to modify border drawing code to prevent this line-ending problem.

I fixed the problem with borders in "draw cell background below hidden border sides" mode.

Here is how your document looks like after importing from RTF now:

As for the line ending problem.
I can reproduce it, but not to the extent that is shown on your screenshots.
In my tests, it looks like the problems are only because rounded line caps.
I'll try to add an option to use rectangles for drawing lines.

Update:
Ok, these minor rounding caps problems occur if PDF was created at 600 DPI.
When creating it at 96 DPI, I can see the problems like on your screenshot...

I am working on this problem.

This how PDF generated using SynPDF looks now:

(with "cell background below borders" option)

So all the problems in this topic are solved, and fixes will be included in the next update.
The only open question is formula fields in RTF, but we can discuss how to import/export them better.

Nice to see - how quick you are solving such issues.
I have some more points on my list - beacause I tried to implement some other functions, but for these I will open a new thread.

with best regards

André

The fixes are included in TRichView 20.1 (uploaded today)