Help with 'C' conversion please?

[Michael Mattias]

Using: LIBHARU 2.08 PDF library; available at http://libharu.sourceforge.net/

Function declaration from documentation:

#include "apdf.h"

typedef struct _HPDF_TextWidth {
    HPDF_UINT numchars;
    HPDF_UINT numwords;
    HPDF_UINT width;
    HPDF_UINT numspace;
} HPDF_TextWidth;

HPDF_TextWidth
HPDF_Font_TextWidth  (HPDF_Font          font,
                      const HPDF_BYTE   *text,
                      HPDF_UINT          len);

My PB code so far:

TYPE HPDF_TEXT_WIDTH
   numchar   AS LONG
   numWord   AS LONG
   nwidth    AS LONG
   nSpace    AS LONG
END TYPE
...
DECLARE FUNCTION HPDF_Font_TextWidth libharu_call libharu_dll ALIAS "HPDF_Font_TextWidth" _
    (BYVAL hFont AS LONG, szText AS ASCIIZ, BYVAL iLen AS LONG) AS LONG

    LOCAL pTW AS HPDF_TEXT_WIDTH PTR
    LOCAL TW  AS HPDF_TEXT_WIDTH

    CALL   HPDF_Font_TextWidth ( hFont(0), szText, LSTRLEN(szText)) TO pTW

From hPDF.h:

HPDF_EXPORT(HPDF_TextWidth)
HPDF_Font_TextWidth  (HPDF_Font          font,
                      const HPDF_BYTE   *text,
                      HPDF_UINT          len);

There is no 'apdf.h' file in the package.


What files / portions of files would I need to post for someone to tell me how that structure is returned? That is, how I can get the values from the returned structure in my PB/Win 8.03 program?

I thought HPDF_Font_textWidth might return a pointer to a structure - multiple calls always return the same value within any one run of the program, eg 1267862, which sure looks like a pointer - but that did not work out for me.

Anything worth a try appreciated. I can do what I need to do with what I have working but it is definitely going the long way and making this call work would simplify my life a lot.

Thanks,
MCM

[José Roca]

When compiling functions that return structures or unions, GCC output code normally uses a method different from that used on most versions of Unix. As a result, code compiled with GCC cannot call a structure-returning function compiled with PCC, and vice versa.

The method used by GCC is as follows: a structure or union which is 1, 2, 4 or 8 bytes long is returned like a scalar. A structure or union with any other size is stored into an address supplied by the caller (usually in a special, fixed register, but on some machines it is passed on the stack). The target hook TARGET_STRUCT_VALUE_RTX tells GCC where to pass this address.

By contrast, PCC on most target machines returns structures and unions of any size by copying the data into an area of static storage, and then returning the address of that storage as if it were a pointer value. The caller must copy the data from that memory area to the place where the value is wanted. GCC does not use this method because it is slower and nonreentrant.

On some newer machines, PCC uses a reentrant convention for all structure and union returning. GCC on most of these machines uses a compatible convention when returning structures and unions in memory, but still returns small structures and unions in registers.

http://gcc.gnu.org/onlinedocs/gcc/In...ibilities.html

As the functions that return an structure didn't work with Delphi, the author wrote "2" functions, e.g. HPDF_Image_GetSize2, that return the value in a structure passed by reference. But for some reason he chose not to do it with all of them.

[Michael Mattias]

Well, I tried again and discovered that what is returned MIGHT be a pointer to that structure, but here the doc says...

When HPDF_Font_TextWidth() succeed, it returns a HPDF_TextWidth struct including calculation result. Otherwise, it returns a HPDF_TextWidth struct whose attributes are all ZERO.

OK, I get the structure with all Zeros... but the internal "getError" function does not return an error code, and then the program GPFs.

Ok, well, let's just forget aout it. I can do word counts and space counts by other means; there is another function to actually measure the text so I can wordwrap it myself.

FWIW, I have also noticed that function call is strange, in that it does not require a "font size" (the font handles are not sized at all). How could you possibly get the length of text in dots/pixels when you don't know the font size?

[Paul Franks]

FWIW, I have also noticed that function call is strange, in that it does not require a "font size" (the font handles are not sized at all). How could you possibly get the length of text in dots/pixels when you don't know the font size?

PDFs are normally measured in points, never in dots/pixels (get used to dividing by 72).

A peek at the docs for HPDF_Font_GetUnicodeWidth reveals this:

char_width = HPDF_Font_GetUnicodeWidth (font, UNICODE);
float actual_width = char_width * FONT_SIZE / 1000;

I'm guessing you will need to calculate the actual_width for the function in question, as well, based on the desired font size.

BTW, you're a version out of date: http://libharu.org/wiki/Downloads

[Michael Mattias]

>you're a version out of date

Version 2.1.0 (first following 2.0.8) was released 5-27-08.

When I started this project I was current. Heck, I tested it to quote the job in March.

Oh, well, I have a universal disclaimer in the contract which says client's elective use of new operating systems, utilities or libraries is not covered by the warranty.

Actually, I am not getting handy at dividing/multiplying by 72; I wrote some functions/macros to convert inches to "haru units" and don't have to think about it.

The 'points' unit of measure was not as tough for me to handle as is the fact that Haru uses a coordinate system with (0,0) at the lower left of the page instead of the more familiar upper left. But I have a function or macro or something to handle that, too.





MCM

[Paul Franks]

The 'points' unit of measure was not as tough for me to handle as is the fact that Haru uses a coordinate system with (0,0) at the lower left of the page instead of the more familiar upper left.

It ain't libHaru's coordinate system, it's Adobe's. All the PDF libraries I've used, including libHaru, pdflib, iText, PoDoFo, and iSedQuickPDF use it.