Re: [ft-devel] Updates for GF driver.

[Werner LEMBERG]

[Please send such e-mails to the mailing list also.]

> Just a heads up that I have added a base code to all the functions
> required for the GF driver. I have also made most of the changes
> which you instructed in the last mail.

Great!

> Currently I am working on the possibilities of filling the parent
> fields from the driver specific variables.  Once I complete this I
> will move to building the driver and removing the possible errors.

OK.

> Now for checking the output I wish to use the example code for
> testing.  I wanted to ask if you suggest any other way to check the
> output of the driver.

What about adding a lot of tracing messages to get output similar (but
not necessarily identical or as detailed) to `gftype -mnemonics' and
later on `pktype'?  This should simplify verification of the code.

Later on, I suggest that you simply build `ftview'; it should
automatically handle GF files if the driver is properly installed into
FreeType.

> Also I want to ask you for any feedback or instructions you wish to
> give me.  [...]

I did

  git diff f999375 1c48e9a

to compare `master' with `parthw-wip'.  Here are my remarks.

* Does your code already compile?  If not, I suggest to add dummy code
  to achieve that.  In general, it is always a good idea to have only
  compilable code in the repository, since it makes `git bisect' much
  easier later on.

* Run Nikhil's `docconverter.py' and `markify.py' scripts (from his
  `freetype-docs' repository) to convert all block comments into the
  `light' format.  And please check whether the headers are correct –
  for example, `gflib.c' identifies itself as `gfdrivr.h'...

* `GF_Face_Init':

  - you have isolated code blocks `{ ... }' (not part of `if', `for',
    etc.) that are indented too much.

  - Setting the PID/EID values of the cmap to `Apple Unicode/Apple ID
    default' is just dummy code, right?  Most certainly you need to
    parse

      xxx 'codingscheme=TeX text'

    (as shown by `gftype' if present in the GF file) to get the right
    character to glyph mapping – those tables are missing, too.

    Please mark such code as preliminary so that I know that something
    is still missing.

* Minor formatting nit: Please indent switch statements as

    switch (foo)
    {
    bar:
      blabla();
    baz:
      urgh();
    }

  In general, labels are outdented by two spaces.

* Robustness: Please have always in mind that malformed GF files must
  be either sanitized or properly rejected.  Not sure whether this is
  an issue, but GF commands like `paint3' can handle quite large
  values...

* There is no code yet in `gf_load_font' to recognize the GF format
  (returning `not a GF font' otherwise).  According to `texdoc gftype'
  it seems that you should test for (GF_PRE,131) as the first two
  bytes, followed by some more tests to be rather sure that the font
  is a GF file at all.

* There are still some tab characters in the source code...

That's it for now.  I have to leave :-)


    Werner