Re: GDI does not provide all GLYPH handles for big font size

Hello,

If you re-examine my code snippets, you will see that for smaller fonts
pstro->pgp comes
into DrvTextOut() already defined, in which case you can use the for( ) loop
to access each letter.

For larger fonts (your #2) pstro->pgp comes into DrvTextOut() as NULL and
you have to
get each letter by way of the outer do loop. In this case the for( ) loop
will only execute once.
The other letters are accessed by the next call to STROBJ_bEnum() in the
outer do loop.

SMC


"fussa" <mailbox.AF@xxxxxx> wrote in message
news:ePP%23aOc5FHA.1032@xxxxxxxxxxxxxxxxxxxxxxx
> "S. Mark Courter schrieb",
>
> hi,
>
> nearly the same code I have written before I have seen your mail for my
> driver. I have done some debug outputs and got following results for the
> code sniple below.
> 1. The call of function "STROBJ_bEnum" only works till font size 150.
> Bigger fonts are passed by GDI as pathes. These pathes are formed not
fine.
> 2. Function "STROBJ_bEnum" proviedes for font size between 54 and 100 or
> 110 only the first character of a string object STROBJ. Example: Let
> assume we have The string "We". The code below runs the "do-while"
> section twice and provides for every run only the glyph for "W". The "e"
> will never put out.
> 3. If function "STROBJ_bEnum" runs with font size <54 all works fine.
> The "for" section in code below will receive all glyphs, so I can render
> every character.
>
>
> It would be very kindfull, if someone could provide some information
> about how all glyphs can be received. Maybe there is a documentation
> which can help?
>
> Thank you.
>
> src code:
> "...
> do
> {
> //
> // We need to enum for more glyph data so do it now.
> //
>
> if (MoreGlyphs)
> {
> MoreGlyphs = STROBJ_bEnum(pstro, &cGlyphs, &pgpos);
>
> if (MoreGlyphs == DDI_ERROR)
> {
> VERBOSE(("DrvTextOut: STROBJ_bEnum()=DDI_ERROR"));
> return(FALSE);
> }
> }
>
> // loop thru array of glyph info
> for( gpInd = 0; gpInd < cGlyphs; gpInd++, pgpos++ )
> {
> ..."


.

Relevant Pages

  • Re: Different behaviour of NimbusMonL-Bold and Courier-Bold in PDF created by pdfwrite
    ... sounds like they are using different fonts for Courier- ... ...Ghostscript never does embed Courier or Courier-Bold, ... Some of the glyphs have ... response to a given character code may be differnt between the two ...
    (comp.lang.postscript)
  • Re: Fonts
    ... cannot display downloaded glyphs. ... I am completely confused on how WWW browsers render ... perfectly rendered almost all the fonts from the above ... and Russian seems to rule. ...
    (comp.os.os2.apps)
  • Re: Different behaviour of NimbusMonL-Bold and Courier-Bold in PDF created by pdfwrite
    ... Some of the glyphs have ... characters" on pages 3-6 may well be due to the fact that both files ... Assuming that the Courier fonts on the two systems are different (see ... THis also explains the slight positioning differences you see ...
    (comp.lang.postscript)
  • Re: TTF2TFM
    ... TeX uses numbers and not names to refer to glyphs. ... >generate T1/TS1 encoded fonts as well as to correct kerning flaws. ... dvips handles ttf fonts in exactly the same way. ... Yes, pdftex does use PostScript-style encoding files for ttf fonts, ...
    (comp.text.tex)
  • Re: Serious problem with java font animation
    ... Create an array of fonts with Font.deriveFontin the ... the animation loop is like this: ... public void paint{ ... private int textSize; ...
    (comp.lang.java.programmer)