TRichView.com

Hi Ilya and Sergey,

I played a bit with the ScaleRichView-enabled ActionTest. Nice start. I noticed a few problems though, so here they are.

Doing "page down" on the vertical scrollbar moves down by only ~4 lines. PageDown key was initially doing the same - until I hit the circular button at the bottom of the vertical scrollbar, and chose "picture".

The associated up/down arrow buttons started selecting previous/next picture, but not scrolling the document to bring the selected picture into view. Same with links.

In normal view mode, put cursor at top of document, increase the top margin using the vertical ruler by several lines -> the carret ends up above the top of the text (roughly where it was before).

Just moving the carret left/right/up/down in the text is extremely slow.

Background "binder" graphic of the document is aligned with the left edge of the page, not the left margin.

It ignores if we set printer settings to landscape paper orientation.

It allows margins to be set to zero, ignoring printer's minimums.

Change from 25% zoom with cursor in the 3rd page to Full Page zoom displays page 1.

The carret is almost invisible (just the top 2 pixels at best) in lines at the very bottom of the page (tried in page 3, PageWidth zoom).

This looks very promising (although alas not for Alventis... we have our own GUI that doesn't rely on Actions).

Best regards,

As for dependence on RichViewActions, this component only uses ruler from there. All other RichViewActions features are optional and they will not be added to your application's code if you do not use them.
As for the bugs, Ilya will fix them in the next update.

Thank you for the bug report. These bugs will be fixed in next updates.
There is one bug that I cannot reproduce: "The carret is almost invisible (just the top 2 pixels at best) in lines at the very bottom of the page (tried in page 3, PageWidth zoom).". Can you give me more details about it?

Re: dependence on RichViewActions, Okay, understood. That's good news. Thanks, Sergey.

Re: The carret is almost invisible...
I tried again and, yes, it's not easy to reproduce, but I managed. Try this: set zoom to FullPage (simply to see the whole thing) and start to gradually reduce the top margin (using the vertical ruler) until a "new" line jumps from the next page at the bottom of the current one. Put the cursor on that line -> it's cut-off.
Alternative: as above, go to FullPage. On my system, the bottommost line on page 1 is "How to use" heading. Put the cursor on that line. Start reducing (1 "pixel" at a time) the top margin. The cursor is getting gradually cut-off (even before the next line appears).
Note that there seems to be an additional problem with the last line (possibly unrelated to carret cut-off): if that last line is bulleted/numbered, the number will not appear (it does appear in the printout though).

And while we're at it, here's one more problem: in all views, attempts to select lines by dragging the mouse in the left margin (you know, where the pointer arrow turns to the right) results in proper selection - but only after one releases the mouse button (i.e., there's no update while dragging in the margin, only if dragging in the text).

And one more: I tried to print an A4-size document to Acrobat Distiller from the non-page-layout modes. The output was a single Letter (8.5"x11") page with the entire text on a single page. Horizontally, it was correct, but vertically, it was squished by a factor of ~5 (to fit).

In page layout mode, printing to PDF worked mostly fine, but page numbers appeared over the text (about 1" above the bottom margin).

Finally (well, maybe ), some letter pairs appear to be much closer to one another than they should be. This happens even at 500% zoom. Such "overly kerned" letter pairs are, e.g., ve, vi, vf (v-anything?), other pairs at other zoom levels (at 150%: It, fo, fi, ft, In, du), and so on. Nothing deadly, but not very pretty. Maybe the letter positioning calculations can be tweaked a bit?

Hope this helps,

Finally (well, maybe Wink), some letter pairs appear to be much closer to one another than they should be. This happens even at 500% zoom. Such "overly kerned" letter pairs are, e.g., ve, vi, vf (v-anything?), other pairs at other zoom levels (at 150%: It, fo, fi, ft, In, du), and so on. Nothing deadly, but not very pretty. Maybe the letter positioning calculations can be tweaked a bit?

The problem in Metafile Windows - after scaling (exception of 100 %) as access to it occurs by means of integer values (X, Y) after scaling they fractional, but to a fractional part at Canvas is not present access. The Same problem, is sometimes observed and in MS Word. In due course I shall change algorithm of a conclusion.

Thanks for the information Michel.
All other problems in the near future will be corrected.

Hi Ilya,

Re/scaling: yea, I suspected that much. Oh well, too bad.

Keep up the good work!

All is corrected. In the near future the new release will uploaded.