Remaining text after printing a line

[Brent Rose]

(I'm new to VPE and trying to get a handle on how it works)

If I write a string which is clipped, how can I determine the remaining (clipped and unprinted) text?

AIM: I want to write the remaining text eg in a second column on the same page.

eg In the following, when the string is written to a single line using nRenderHeight, the final "string." text is clipped. When written using VFREE, the same text is wrapped to a second line as expected. I want to write "string." somewhere else.

Code: Select all

with ReportEngine do
begin
  OpenDoc;
  RenderWrite(2.0, 2.0, 5.0, VFREE, 'X');
  Write(2.0, 2.0, 5.0, 2.0 + nRenderHeight, 'This is my sample string.');
  Write(12.0, 2.0, 15.0, VFREE, 'This is my sample string.');      
  Preview;
end;

[IDEAL Software Support]

It is currently not possible to determine the text position. We are considering to implement this in a later version.

But you can use the following workaround:
1) Determine the height of a single character using RenderWrite() with y2 = VFREE / nFree and store it in a variable "SingleLineHeight"
2) Render the whole string you wish to output using RenderWrite() with y2 = VFREE / nFree
3) If the height is greater than SingleLineHeight, shorten the string by a word and goto (2)

This could be optimized by using some sort of binary search, i.e. do not shorten the string by a single word, but cut in the middle on a word boundary and repeat this process for the first (RenderHeight > SingleLineHeight) or second half (RenderHeight <= SingleLineHeight) of the string, etc. You'll need to find some tricky point where to stop this process, maybe by turning over to a linear search after approximating to a good result.

[Brent Rose]

Thank you. I'll give this a go - it is pretty essential reporting functionality (I don't see VPE working so well for me without it)...

Maybe the "average character width" (generally width of "x" according to MS SDK) would best predict the optimal start point to word-scan forward or back from as required.

Are you also planning to include access to TextMetrics (viz font ascent and descent heights etc)? This would be pretty important for positioning text with respect to the FONT top/bottom etc. I assume I'll be able use standard Windows calls to get this data in the meantime...

[IDEAL Software Support]

We have no plans to do so. If you wish to align text of different fonts and / or font sizes on the same baseline, you should use the RTF (Rich Text) object, provided by the Professional Edition and higher.

[Brent Rose]

OK - thanks for that. Yes, I do want to align different fonts on the same baseline, but also (commonly) align the top-of-font at a fixed vertical position etc etc. Trying to use RTF to achieve these basics seems a somewhat cumbersome and inefficient way of handling plain text - and probably will not work in all cases anyway.

I understand that VPE has been designed as a superfast reporting engine (which is great), but, IMHO, the lack of text-wrapping capability and precise text-positioning capability are pretty fundamental and glaring gaps in the scope of an otherwise comprehensive reporting tool. In fact, given how much work would be involved in adding these features, and the enormous gain in functionality and utility thus achieved, I am very surprised they are missing. Also surprised that eg the Pro-version is as much as 998 euro WITHOUT such basics.

However, I am currently trying to write a component to implement the plain text-wrapping. So far, so good. I'll then have to see if I can derive the TEXTMETRICs satisfactorily within VPE. If I can achieve these goals, then I'll almost certainly buy a copy of VPE knowing I can develop the other essentials for my reporting requirements from there... (A shame that VPE is DLL dependent and not native VCL - but I can live with that).

...but I would still respectfully suggest that exposing TEXTMETRICs would be a very simple way to greatly enhance the text-positioning capabilities of VPE

[IDEAL Software Support]

Maybe this is a misunderstanding. When you are using RTF, you specify the vertical top-position of the text, but the text itself is base-line aligned. This means the portion of text with the biggest height is aligned with its top to the specified vertical top-position.

We see no real use-case for providing text metrics - in fact you are the second of thousands of users (since 1996) asking for such a feature.

A shame that VPE is DLL dependent and not native VCL - but I can live with that

We can not leave this uncommented. Until today, C/C++ is the only language which allows to develop code for different platforms and to support different programming languages. Using Delphi we could not support Mac OS X, Linux and Solaris. In addition VPE is shipped as Delphi VCL, ActiveX, .NET component and Java component (PHP, Python, Ruby and Perl are currently under development). All this is achieved by wrapping in each case the original C++ DLL (.so, .dylib) inside of programming language specific code.

[Brent Rose]

OK - I'll have to look more closely at the RTF features (although still not quite sure how this relates efficiently to routinely using plain text only). My understanding at this stage is that you can only position text by TOP-OF-LINE, not, say, TOP-OF-FONT (difference is LINE HEIGHT - ASCENT HEIGHT - DESCENT HEIGHT) or FONT-BASELINE (difference is LINE HEIGHT - DESCENT HEIGHT).

I fully appreciate that your priorities must reflect "popular demand" - and as only one-of-two confessing to wanting TEXTMETRICS such a feature doesn't really rate. Fair enough. Hopefully I can derive the required metrics with the Windows API etc...

About the DLL - yes, fair comment. I understand that one of the advantages of VPE is that it IS cross platform. I only wished to point out that not having to distribute a DLL for my Delphi applications (in particular) would be the "ideal", but to gain the reporting functionality and flexibility VPE seems to offer, using a DLL will be fine. No offence intended.

[IDEAL Software Support]

May I ask for what purpose you require to work with text metrics? It is one of VPE's intentions to hide such low-level things away from the user. But for sure you have a good reason to use it.

[Brent Rose]

Sure. In a nut shell, access to TEXTMETRICS allows precise positioning of text by FONT rather than LINE. Granted, in some cases you can to achieve a similar result by reasonable guess-work, but it is much easier with the text metrics. Some instances where I use the metrics are:

1. I want to align text adjacent to a logo image, a top line even with the top of the image, a bottom line even with the bottom of the image. Roughly:

XXXXXXXX TOP LINE
XXXXXXXX
XXXXXXXX BOTTOM LINE

I need FONT-TOP to correctly align the top line, and FONT-BASELINE to correctly align the bottom line.

2. With natural line spacing in something like:

LARGE TEXT
SMALL TEXT

the normal gap between the lines is too large (in my given case). Instead, I want to accurately position the SMALL TEXT 0.5mm below the LARGE TEXT. Easiest way is to take FONT-BASELINE of LARGE TEXT plus 0.5mm equals FONT-TOP of SMALL TEXT.

3. I want to centre a line or arrow or bullet point on a caption or line of text. eg Roughly:

------> MY CAPTION

I would position the line on FONT-MIDDLE, or position the text by FONT-MIDDLE on the line.

4. I have a multi page report in which I always want text to visually start at exactly the same point below the page header (where I have some images starting too) regardless of the font used at the time. I would simply set by FONT-TOP to this vertical position.

5. With text of varying fonts on the same line like:

TEXT TEXT TEXT TEXT TEXT

you typically want to align the FONT-BASELINE, but you may also want to align the FONT-TOP or FONT-MIDDLE instead.

6. If you wanted to nicely centre some TEXT between two horizontal lines on a form, best way is relative to FONT-MIDDLE.

7. I want to label dimension lines on a simply diagramme - I need to centre my dimension numbers exactly on the line (ie by FONT-MIDDLE)

8. Plus other cases where text positioning is sensitive...

VPE Rendering allows calculation of LINE-HEIGHT, so LINE-TOP, LINE-MIDDLE, and LINE-BOTTOM can be derived.

However, within that vertical line space, you need font ascent and descent heights to determine FONT-TOP, FONT-MIDDLE (middle-of-ascent), FONT-BASELINE. FONT-BOTTOM would be the same as LINE-BOTTOM. With VPE as it stands, and access to the metrics, one would be able to calculate the correct "Top" value to use for the existing Write() and Print() procedures etc. In this context one might create simple utility functions to return an appropriate "Top" for these procedures - eg TopByFontTop(MyDesiredFontTop), TopByFontBaseLine(MyDesiredFontBaseLine) etc etc. You would still want access to ascent/descent values, though.

Hiding low-level details like this from the user makes perfect sense (afterall, you generally do not need them) - but, IMHO, still having it available exposes some extremely useful raw power.

[IDEAL Software Support]

This gives some good insight into your requirements. We think most of them are related to tasks required from a designers view - except baseline alignment, which is available through he RTF object. I would like to note that the design-specific tasks can be solved using our visual designer "dycodoc", which comes with the Enterprise Edition. But this does not allow to solve the problems programmatically, therefore we will put this onto our internal "Wishlist", but I can not promise when or if this is going to be implemented.

But I can be of help for you, because there is an undocumented feature in the Professional Edition (which was implemented - as a paid enhancement - for the single customer I mentioned in a previous post):
The VPE DLL function VpeGet() can be provided the special parameter VASCENT (which has the value -110), which will return the ascent of the currently selected font (in the units specified by UnitTransformation). This way you can also compute the font's descent by subtracting the ascent from the height returned by RenderPrint() or RenderWrite().

You are using Delphi and the source code for the Delphi VPE component is shipped with VPE. Therefore it is a snap to enhance the component's source code with a new method or property that will call the VPE function VpeGet(hDocument, -110) and return its value.

If you are asking why we do hesitate to release this API publicly: we have source code generators that create major parts of the .NET, VCL, ActiveX, etc. automatically. But the generators can not handle VpeGet(), therefore we would need to create a new (set of) functions inside the VPE DLL, which return text metrics. As mentioned - we have put this onto the wishlist now.

[Brent Rose]

Thank you - this looks really promising! I have modified the VCL source as you suggest, and can now happily derive the AscentHeight. Using your suggested calculation has enabled me to determine the font baseline - the code below successfully draws a line at LINE-TOP, LINE-BOTTOM, and FONT-BASELINE using a new property "FontAscentHeight".

However, there are insufficient metrics to determine FONT-TOP. I think the required measurement might be "InternalLeading" - there seem to be differing interpretations of exactly what these metrics mean.

I have guessed InternalLeading for the font in the code sample below in order to draw a line at FONT-TOP. You can see what I'm trying to achieve.

Is there any possibility of coming to some arrangement to get additional metrics? I might <assume> that if VASCENT is available, the others could be exposed in a similar fashion...

Thanks.

Code: Select all

var
   hRender: Double;
   hAscent, hDescent, hInternalLeading: Double;
begin
   with ReportEngine do
   begin
      OpenDoc;
      SetFont('Arial', 72);

      RenderWrite(2.0, 2.0, 2.0, VFREE, 'X');
      hRender := nRenderHeight;

      hAscent := FontAscentHeight;
      hDescent := (hRender - hAscent);

      //guess
      hInternalLeading := 0.520;


      Line(2.0, 2.0, 18.0, 2.0);
      Line(2.0, (2.0 + hInternalLeading), 18.0, (2.0 + hInternalLeading));

      Print(2.0, 2.0, 'My Text Line.');

      Line(2.0, (2.0 + hRender - hDescent), 18.0, (2.0 + hRender - hDescent));
      Line(2.0, (2.0 + hRender), 18.0, (2.0 + hRender));

      Preview;
   end;

[IDEAL Software Support]

If you wish to have this implemented as a special feature, please contact us by e-mail.