Yes. Sorry for that. Actually I was going to send this as a reply to other email but then turned to a new mail and just forgot about the cc'ing part.
>> 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.
Yes! Will do.
>Later on, I suggest that you simply build `ftview'; it should
>automatically handle GF files if the driver is properly installed into
>FreeType.
Ok
>> 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.
Ok.
>* Run Nikhil's `docconverter.py' and `markify.py' scripts (from his
> `freetype-docs' repository) to convert all block comments into the
> `light' format.
Yes.
And please check whether the headers are correct –
> for example, `gflib.c' identifies itself as `gfdrivr.h'...
Uh oh, Sorry I missed that.
>* `GF_Face_Init':
> - you have isolated code blocks `{ ... }' (not part of `if', `for',
> etc.) that are indented too much.
Ok.
> - Setting the PID/EID values of the cmap to `Apple Unicode/Apple ID
> default' is just dummy code, right?
Yes ;)
>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.
Yes. I think I will have to study this part a bit. Thanks.
> Please mark such code as preliminary so that I know that something
> is still missing.
Will take care from next time
>* Minor formatting nit: Please indent switch statements as
> switch (foo)
> {
> bar:
> blabla();
> baz:
> urgh();
> }
> In general, labels are outdented by two spaces.
Ok
>* 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...
I have already added checks for `post_post` instruction which checks for GF_ID
and returns `Invalid_File_Format` if not found so,
and some more checks which checks for GF files' validity in `gf_load_font`.
Similar to what done in Vflib.
Do you suggest anything more? And yes I'll check for the paint3 part.
>* There is no code yet in `gf_load_font' to recognize the GF format
> (returning `not a GF font' otherwise).
Isn't this same as done above, for `Invalid_File_Format`?
> 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.
Ok.
It currently checks for GF_POST_POST, GF_POST and GF_ID. I will also add functionality for GF_PRE.
>* There are still some tab characters in the source code...
Uh Oh. Sorry for that.
Thank you
--
Parth