>
> >[Please send such e-mails to the mailing list also.]
>
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
_______________________________________________
Freetype-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype-devel
