> > 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
https://l
> 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 ho
> 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 paragraph
>> * 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 the
> 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:
>
> 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
> > 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 w
> 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,
a
> 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
> hav
> 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 i
>> 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 ‘
> 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’. No
>>> 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
co
>> 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,
which
> 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 expe
>> * 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. Pl
> 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 later
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 b18f5e7c62c0aa6f8d17cbb9a8fe687ed402569a
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 days.
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 outpu
20 matches
Mail list logo
