Re: [ft-devel] GSoC status update.

> > >> I wonder whether it makes sense to add an artificial space glyph to > >> the GF + TFM combo – most font formats have a space glyph for > >> simple string support... What do you think? > >> > >> The width of such a space glyph could be derived from TFM's > >> `param[2]' value. > > > > I

Re: [ft-devel] GSoC status update.

>> I wonder whether it makes sense to add an artificial space glyph to >> the GF + TFM combo – most font formats have a space glyph for >> simple string support... What do you think? >> >> The width of such a space glyph could be derived from TFM's >> `param[2]' value. > > I don't really know

Re: [ft-devel] GSoC status update.

> > Now `ftview' displays the gf glyphs too! > I am attaching a screenshot of the output from `ftview' and `ftstring'! > [...] > I have cleaned up the code for `gf driver' in the branch `parthw-cleaned', removed all unnecessary typedefs and comments. I have currently tested for many `gf' files,

Re: [ft-devel] GSoC status update.

> > >> Now `ftview' displays the gf glyphs too! I am attaching a > >> screenshot of the output from `ftview' and `ftstring'! [...] > > Looks good, thanks! > > I wonder whether it makes sense to add an artificial space glyph to > the GF + TFM combo – most font formats have a space glyph for

Re: [ft-devel] GSoC status update.

> > >>> Perhaps there is some missing documentation or a missing > >>> explanatory comment in the code... > > > > Hmm, maybe a note on this could go into `FreeType Design / IV', as a > > list of services all drivers are required to implement. > > Good idea! Parth, please file a bug report (with

Re: [ft-devel] GSoC status update.

>> Now `ftview' displays the gf glyphs too! I am attaching a >> screenshot of the output from `ftview' and `ftstring'! [...] Looks good, thanks! I wonder whether it makes sense to add an artificial space glyph to the GF + TFM combo – most font formats have a space glyph for simple string

Re: [ft-devel] GSoC status update.

>>> Perhaps there is some missing documentation or a missing >>> explanatory comment in the code... > > Hmm, maybe a note on this could go into `FreeType Design / IV', as a > list of services all drivers are required to implement. Good idea! Parth, please file a bug report (with item group

Re: [ft-devel] GSoC status update.

>> Please tell me why you wasn't able to identify the problem by >> yourself! > > > Actually, I thought that these services are not a regular part of > the module and are defined only if there are functions of the driver > required outside the driver, so I did not define them. Ah, ok. > But,

Re: [ft-devel] GSoC status update.

> >>> I've still not found time to have a closer look at the issue, sorry >>> >>> (still on vacation more or less). Please try to debug it by >>> >>> yourself also – I can only assist, since it's actually your job to >>> >>> find the bug... >>> >> >>> >> Yes, I am working on it. If you could

Re: [ft-devel] GSoC status update.

> > >>> I've still not found time to have a closer look at the issue, sorry > >>> (still on vacation more or less). Please try to debug it by > >>> yourself also – I can only assist, since it's actually your job to > >>> find the bug... > >> > >> Yes, I am working on it. If you could just give

Re: [ft-devel] GSoC status update.

>>> I've still not found time to have a closer look at the issue, sorry >>> (still on vacation more or less). Please try to debug it by >>> yourself also – I can only assist, since it's actually your job to >>> find the bug... >> >> Yes, I am working on it. If you could just give me a lead

Re: [ft-devel] GSoC status update.

> > >> I've still not found time to have a closer look at the issue, sorry > >> (still on vacation more or less). Please try to debug it by > >> yourself also – I can only assist, since it's actually your job to > >> find the bug... > > > > Yes, I am working on it. If you could just give me a

Re: [ft-devel] GSoC status update.

>> I've still not found time to have a closer look at the issue, sorry >> (still on vacation more or less). Please try to debug it by >> yourself also – I can only assist, since it's actually your job to >> find the bug... > > Yes, I am working on it. If you could just give me a lead like >

Re: [ft-devel] GSoC status update.

> > > * GF Driver: I have added support for parsing the `xxx' and `yyy' > > commands. Now the gf driver supports all the `gf' font files! I am > > working on the possibilities of parsing information from these > > commands. > > Good. Does `ftview' amd friends already work? No not yet. >

Re: [ft-devel] GSoC status update.

> * GF Driver: I have added support for parsing the `xxx' and `yyy' > commands. Now the gf driver supports all the `gf' font files! I am > working on the possibilities of parsing information from these > commands. Good. Does `ftview' amd friends already work? I've still not found time to

[ft-devel] GSoC status update.

Hi all, Here are some quick updates, * GF Driver: I have added support for parsing the `xxx' and `yyy' commands. Now the gf driver supports all the `gf' font files! I am working on the possibilities of parsing information from these commands. * PK Driver: The `pk' driver is almost similar to the

Re: [ft-devel] GSoC Status update

> I have cleaned up the code and now gf driver has all the code > required to run the driver, the driver is now properly extracting > the information correctly from the font file. All the > `gf_driver_class' functions are also complete now. Excellent. Will test soon. > But, when I run

Re: [ft-devel] GSoC Status update

> > > * About the testing of the gf driver, there are still some issues >> > left to be sorted out. I am working on them. >> >> What I want to have is code in your `gf' module so that `ftview' can >> display GF fonts. >> > > I have cleaned up the code and now gf driver has all the code required

Re: [ft-devel] GSoC Status update

> > > * About the testing of the gf driver, there are still some issues > > left to be sorted out. I am working on them. > > What I want to have is code in your `gf' module so that `ftview' can > display GF fonts. When will you reach that point? > I have cleaned up the code and now gf driver

Re: [ft-devel] GSoC Status update

> * I had been working on the stream support for the gf driver for > quite a while now, and I have completed it. Good! > * About the testing of the gf driver, there are still some issues > left to be sorted out. I am working on them. What I want to have is code in your `gf' module so

Re: [ft-devel] GSoC Status update and complete API reference website

> > See the attached screenshots, for an idea of how this will work. > > Looks good! > Great, changes implemented and wiki updated! I have removed the original tilde method. -- Nikhil ___ Freetype-devel mailing list Freetype-devel@nongnu.org

[ft-devel] GSoC Status update

Hi all, * I had been working on the stream support for the gf driver for quite a while now, and I have completed it. * About the testing of the gf driver, there are still some issues left to be sorted out. I am working on them. * I have already started working on the tfm driver. I intend to work

Re: [ft-devel] GSoC Status update and complete API reference website

> I just realized that this would cause a problem with nested lists. > A solution here is to indent multi-paragraph lists to 4 spaces in > the docs itself, so that docwriter is freed from the responsibility > of keeping track of the spaces. Yes. > See the attached screenshots, for an idea of

Re: [ft-devel] GSoC Status update and complete API reference website

> Hmm. What about making DocPara strip leading and trailing spaces > *except* for the first leading space in a paragraph? This seems reasonable. This will be implemented as follows: * DocPara will have a new property 'indent' which will store the indentation of the first line of the

Re: [ft-devel] GSoC Status update and complete API reference website

>> * I'm not happy with >> >> To continue a list over multiple paragraphs, start the paragraphs >> with a tilde (~) character. >> >> I would rather prefer that a continuation is indented as before. > > The problem with this is, DocPara objects strip leading and trailing > spaces in

Re: [ft-devel] GSoC Status update and complete API reference website

> Very nice, thanks! > :-) Some issues. > > * s/comfig/config/. Oops, fixed! > * I'm not happy with > > To continue a list over multiple paragraphs, start the paragraphs > with a tilde (~) character. > > I would rather prefer that a continuation is indented as before. > Example:

Re: [ft-devel] GSoC Status update and complete API reference website

> I have written a draft for this document, available at > > https://github.com/nikramakrishnan/freetype-docs/wiki/Documentation-Guidelines-for-The-FreeType-Project Very nice, thanks! Some issues. * s/comfig/config/. * I'm not happy with To continue a list over multiple paragraphs, start

Re: [ft-devel] GSoC Status update and complete API reference website

> > Because we will now switch to markdown, we may have to be careful >> > with the usage of asterisks. They are used to begin points in >> > unordered lists and wrap italics text. >> >> OK. This is something to be added to a forthcoming >> `docs/DOCUMENTATION' file. I invite you to write this

Re: [ft-devel] GSoC Status update and complete API reference website

> Indeed. Essentially, everything that can be used within C code should > be tagged with `...`, for example `FT_Glyph`, `FT_GLYPH_H`, etc. > > Maybe it makes sense to convert everything starting with `FT_...' to > `...`? > These cases are covered by the regex I added, so stuff with underscores,

Re: [ft-devel] GSoC Status update and complete API reference website

> OK, I came up with 2 regex expressions to try and find inline code > sequences, and was able to replace 394 `...' quotes to `...`. All > other quotes will be converted to '...' (these changes were done in > markify.py). > > However, this is *not* fool-proof, and many variable names would >

Re: [ft-devel] GSoC Status update and complete API reference website

> Well, `...' should be eventually resolved into `...` and '...'. > OK, I came up with 2 regex expressions to try and find inline code sequences, and was able to replace 394 `...' quotes to `...`. All other quotes will be converted to '...' (these changes were done in markify.py). However, this

Re: [ft-devel] GSoC Status update and complete API reference website

>> Do you mean in the input or in the output? Right now, `...' in the >> input has two purposes. >> >> (1) It is used as a poor-man's substitute for inline code snippets >> – the thing Nikhil is talking. >> >> (2) It is *really* used for quotations, i.e., `foo' should be >> converted to

Re: [ft-devel] GSoC Status update and complete API reference website

> Do you mean in the input or in the output? Right now, `...' in the > input has two purposes. > > (1) It is used as a poor-man's substitute for inline code snippets – > the thing Nikhil is talking. > > (2) It is *really* used for quotations, i.e., `foo' should be > converted to ‘foo’.

Re: [ft-devel] GSoC Status update and complete API reference website

>>> I do not like `quoted' text. Do you mean in the input or in the output? Right now, `...' in the input has two purposes. (1) It is used as a poor-man's substitute for inline code snippets – the thing Nikhil is talking. (2) It is *really* used for quotations, i.e., `foo' should be

Re: [ft-devel] GSoC Status update and complete API reference website

>> I do not like `quoted' text. > I do have a suggestion - Changing variable names and inline code snippets > to `foobar` instead of `foobar'. Markdown will add an inline code block > around the text (see attached image). Yes, I would prefer this. There was a reason to use different quotes,

Re: [ft-devel] GSoC Status update and complete API reference website

> It is nice that most ordered and unordered lists are picked up. Is it > described somewhere what is recognized as a list? For now any list style supported by markdown should work except in field tables (there is a problem with ordered lists right now, but I am working to fix this). You can

Re: [ft-devel] GSoC Status update and complete API reference website

>> * In the `fields' subsection of each element, please reduce the >> space between the elements. In most cases, the descriptions are >> only a single line, and (at least with my Chrome browser) this >> takes too much vertical space IMHO, see attached image. > > I have reduced the space.

Re: [ft-devel] GSoC Status update and complete API reference website

> Right now I've noticed only two issues. > > * Looking at > > https://nikramakrishnan.github.io/freetype-site/ft2-toc/ > > I wonder why the `Docs' link in > > Docs » Table of Contents > > points to the index. Is this intentional? I assume this is a > temporary decision, since

Re: [ft-devel] GSoC Status update and complete API reference website

On Tue, Jun 12, 2018 at 8:26 AM, Nikhil Ramakrishnan wrote: > * The complete API documentation site is now available on > https://nikramakrishnan.github.io/freetype-site/ft2-toc/ > This was generated using docwriter with the header files > updated to commit

Re: [ft-devel] GSoC Status update and complete API reference website

Hello Nikhil! > * Also, docwriter > (https://github.com/nikramakrishnan/freetype-docwriter) can now > output Markdown, and I am in the process of writing code to > automatically generate the `yml' configuration file required by > MkDocs. Great! Will check that within the next few

[ft-devel] GSoC Status update and complete API reference website

Hi all, * It's been 4 weeks since the coding period for GSoC began and I have written another status update for weeks 3 & 4: https://github.com/nikramakrishnan/freetype-docs/wiki/GSoC-Status-Update:-Week-3-&-4 * Also, docwriter (https://github.com/nikramakrishnan/freetype-docwriter) can now

Re: [ft-devel] [GSoC] Status Update after community bonding period

> I have written a blog post about the community bonding period here > . Nice! > Please let me know if there are any other instructions which you > wish to give me. Nothing specific comes to my mind. Have fun with coding!

[ft-devel] [GSoC] Status Update after community bonding period

Hi all, I have written a blog post about the community bonding period here . I am currently going through the VFlib's codebase and have started gaining insights for the GF driver, I have also started coding for the driver and