Table border printing problem

General TRichView support forum. Please post your questions here
Post Reply
Fellow

Table border printing problem

Post by Fellow »

Two days ago, you helped me to make one pixel border table, and it worked perfect.

But another problem rised.
When I use stylus printer to print these tables, the border is so so so bord, so thick, more than 3 pixel. But if I use laser printer, the tables are beautiful.

Maybe you think it printers' problem, but these printers work well with Word and Excel.

Can you check out this problem?

Thx~
Sergey Tkachenko
Site Admin
Posts: 17569
Joined: Sat Aug 27, 2005 10:28 am
Contact:

Post by Sergey Tkachenko »

Is this a problem with strandard TRichView table printing, or with that procedure for printing one pixel border?
fellow99
Posts: 7
Joined: Tue Oct 18, 2005 8:35 am

Post by fellow99 »

Image
fellow99
Posts: 7
Joined: Tue Oct 18, 2005 8:35 am

Post by fellow99 »

The pic above shows 3 tables:

1. Useing RichViewAction, I insert a table. Then go to "Table properties" and set "Cell spacing" to -1.

2. Created by program:
table.BorderStyle := rvtbColor;
table.BorderWidth := 0;
table.BorderVSpacing := 0;
table.BorderHSpacing := 0;
table.CellBorderStyle := rvtbColor;
table.CellBorderWidth := 1;
table.CellPadding := 3;
table.CellHSpacing := -1;
table.CellVSpacing := -1;

3. Excel table.

===================================

You can see the differences easily.
The Excel table is a true ONE pixel table. The RichViewAction one is a two pixels table. The program created one is worst...
It is not so much as a three pixels table. Some lines' width are more than 4 pixels, and some are thiner.

===================================
My printer is Epson LQ-1600KIIIH, a stylus printer. My OS is win2k pro.
Sergey Tkachenko
Site Admin
Posts: 17569
Joined: Sat Aug 27, 2005 10:28 am
Contact:

Post by Sergey Tkachenko »

Do lines have the same width if cell spacings are positive?
fellow99
Posts: 7
Joined: Tue Oct 18, 2005 8:35 am

Post by fellow99 »

When the cell spacings are positive, 2 for example, the width of the lines are two pixels.

=======================

This is the last question I answer. Please solve my problem as soon as possible. I am very vexed for it. I want to print a large number of tables, and the numbers of each table's cells are alse very LARGE. It is very very guly, and wasted ribbons, and also easy to damage the printer.

Everything is ready except this problem. I don't like to use a report control at this phase of project. Exactly, none of a report control could fulfil my needs except TRichView.

So, please solve my problem as soon as you can.
Sergey Tkachenko
Site Admin
Posts: 17569
Joined: Sat Aug 27, 2005 10:28 am
Contact:

Post by Sergey Tkachenko »

Sorry, but how can I solve this problem without knowing why it happens? I am asking questions not because I am trying to delay the solution, but because I want to know why it goes wrong.

I asked the last question because I want to know if the problem happens because of the border overlapping (may be drawing line two times over the same place makes it wider on that printer).
And sorry, I do not understand your answer. Are the lines have the same width when CellHSpacing=CellVSpacing=-1, and when they are positive values?
fellow99
Posts: 7
Joined: Tue Oct 18, 2005 8:35 am

Post by fellow99 »

I am sorry. Maybe I am too vexed.

=====================================
Image
As you see, the width of the lines are two pixels.
fellow99
Posts: 7
Joined: Tue Oct 18, 2005 8:35 am

Post by fellow99 »

When CellHSpacing=CellVSpacing=-1, It is also like the second instance, the worst one.

In another words, using RichViewAction can print tables with 2 pixels lines, and it is not too bad. But creating tables with programming could not be accepted.

It seems only appear at stylus printers, Maybe.
Michel
Posts: 92
Joined: Fri Oct 14, 2005 2:56 pm
Contact:

Post by Michel »

I don't know if you both have noticed, but maybe this is significant. In the Nov 14, 2005 1:13 pm post with the first big snapshot, in the middle picture marked as "2", the leftmost cell in roughly 9th row from the top appears to have a thinner left border than the other rows. This could indicate cell overlapping, perhaps due to floating point imprecision (on which side, I wouldn't know), but I find it interesting that only one row is different. If I am even seeing it clearly enough. :)
Michel
Sergey Tkachenko
Site Admin
Posts: 17569
Joined: Sat Aug 27, 2005 10:28 am
Contact:

Post by Sergey Tkachenko »

So the lines have the same width when cellspacing = -1 and when it is positive (so the problem is not in the border overlapping)? It seems like this from these scans, but I am not 100% sure.
fellow99
Posts: 7
Joined: Tue Oct 18, 2005 8:35 am

Post by fellow99 »

New discovery

=================================

Image

Image

=================================

I used "Microsoft Office Document Image Writer" as a virtual printer, to output the papers as a image file(.mdi). I snaped parts of the tables.

All tables and all cell were create by programming. It should be the same.
Why? Mystificatory.

You should go over your code and find out the problem.
Sergey Tkachenko
Site Admin
Posts: 17569
Joined: Sat Aug 27, 2005 10:28 am
Contact:

Post by Sergey Tkachenko »

I think the problem with the virtual printer in a rounding off error. And I stronly believe it's not in TRichView but in the printer, because TRichView draws all border lines using the same width (if the image is created in higher resolution and then saved in lower resolution, the virtual printer's rounding off error is understandable, the same artifacts you can see in TRVPrintPreview). I am afraid this problem is not solvable.

But back to the initial problem. I still need an answer to my last question.
fellow99
Posts: 7
Joined: Tue Oct 18, 2005 8:35 am

Post by fellow99 »

I've solved the problem with a middle course.

Code: Select all

for r := 0 to rowCount - 1 do
  for c := 0 to colCount - 1 do
    table.SetCellVisibleBorders(c = 0, r = 0, true, true, r, c);
The codes above can do so on the whole, with litte bug.
I don't like to use this method, but i indeed have no more time.
Sergey Tkachenko
Site Admin
Posts: 17569
Joined: Sat Aug 27, 2005 10:28 am
Contact:

Post by Sergey Tkachenko »

So I believe the problem was in overlapping (drawing the same line over the same place made it thicker).
Ok, this is a temporal solution which I wanted to suggest you to test.
Post Reply