[ft-devel] Questions related to current Documentation (and changes)

nkedin at https://www.linkedin.com/in/nikramakrishnan/ If you could also recommend any other projects that you think is suitable for me, I can start working on a proposal, and take your inputs and comments before submission. I'm looking to forward t

Re: [ft-devel] Questions related to current Documentation (and changes)

g an amazing bunch of output formats. I > don't say that this is the markdown to html generator of choice, but > it seems like a good start. > > > [...] If you could also recommend any other projects that you think > > is suitable for me, I can start working on a proposal, and take your > > inputs and comments before submission. > > Is there anything else besides FreeType? :-) > > > Werner > -- Nikhil Ramakrishnan. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Questions related to current Documentation (and changes)

something > similar, taking away the burden to generate and/or adjust the site > navigation of www.freetype.org. > > Note that the markdown stuff created by (1) will be simply copied and > committed into the `freetype-web' repository, and it should also be > part of w

Re: [ft-devel] Questions related to current Documentation (and changes)

Regards, -- Nikhil Ramakrishnan. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Questions related to current Documentation (and changes)

Hi, I'd like to know whether the project also involves converting the non-documentation pages (Home page, Overview etc.) to markdown, so that the whole site can be deployed at once? I was also thinking about how the API documentation will be generated after the Markdown porting is complete. Will

Re: [ft-devel] [Bug] make refdoc does not show version number (Cygwin)

Hi, [In the future, please send such e-mails to a FreeType list!] > Will do! Thanks a lot. Does the attached patch work for you? It does! I was not very sure about using $(SEP) here, but it works just fine. -- Nikhil ___ Freetype-devel mailing li

[ft-devel] ftmodapi.h: Reference errors

Hi all, I noticed that there are 2 reference errors in include/freetype/ftmodapi.h - FTC_Property_Set and FTC_Property_Get (#362 and #426

[ft-devel] [GSoC 2018] Redevelop FreeType's documentation using markdown

Hi all, Thank you for accepting my proposal for GSoC this year! I am really excited and looking forward to working with FreeType this summer. I would like to spend this month interacting with the community and refining the project plan, including adding more detail and discussing on how things sh

Re: [ft-devel] Custom search functionality & Python3 compatibility of 'docmaker'

Hi, This did not work for me on Python 3. I believe string functions do not work the same in 2 and 3. For instance, there are many of these in content.py , which gives errors with 3. Please confirm. On 16

Re: [ft-devel] Custom search functionality & Python3 compatibility of 'docmaker'

> >Can you share the steps to reproduce errors, for which it is producing > wrong results. > Run `mingw32-make refdoc` (env: Windows, Python 3.6.1) Error text: Traceback (most recent call last): File "./src/tools/docmaker/docmaker.py", line 113, in main( sys.argv ) File "./src/tools/

Re: [ft-devel] Custom search functionality & Python3 compatibility of 'docmaker'

[Please select "Reply all" or include freetype-devel@nongnu.org so others can read the conversation] Ankit, Upon following changes it is working fine but giving more error in cross > references :/.Looking for the reasons but for rest it will work fine > The code now works with Python 3. This in

Re: [ft-devel] Fwd: Custom search functionality & Python3 compatibility of 'docmaker'

Also, the script you sent now stopped working with Python2. @All, On a different note, this brings up a question; Now that the source code documentation is going to be converted to markdown, should the new markdown parser be compatible with both Python versions? Is there a preference? I believe

[ft-devel] Markdown Documentation in header files

Hi all, I was looking through the docmaker and the documentation in the header files. There are a few things I noted: (1) There are two formats for *markup tags*: and @Section There are also two formats for *comment blocks*: /*/ /*

Re: [ft-devel] Markdown Documentation in header files

> I don't object. However, it's a lot of work to walk over the whole > documentation to unify the comment formats, which is dull work I was > always too lazy for doing. > My plan is to automatically do this with a program. In particular, it's not clear to me what > happens with stuff between a c

Re: [ft-devel] Markdown Documentation in header files

Hi, I just noticed this: comment blocks used to define sections use the format even in files where the @Foo: format is exclusively being used. I believe that docmaker is also programmed to recognize these tags specifically in the format. OK, fine. BTW, if you are going to convert all comment

[ft-devel] Conversion of header comments to light format

Hi all, I have been working on the conversion of header comments to the lighter format. That is, from the rectangular blocks to something like this: / * * @Section: *user_allocation * * @Title: *User allocation

[ft-devel] Markdown documentation features

Hi all, I have written a feature draft (conversion) for the documentation in markdown. It is available on my repository's wiki [1]. It covers most of the changes to be made to the current documentation comments in the include/ header files. Please comment and suggest changes (also if I missed so

Re: [ft-devel] Markdown documentation features

> * I sometimes put `meta' comments into square brackets. [Like this.] > Such comments (in the FreeType headers) should not become links. > Text inside one square bracket will not become a link. This requires another line specifying the URL to be a qualified link: Lorem ipsum dolor sit amet,

[ft-devel] GSoC Update: Week 1 & 2

Hi all, It's been 2 weeks since the coding period for GSoC started, and the process of revamping the documentation has started! I've written a status update on the freetype-docs wiki on GitHub [1]. Please have

Re: [ft-devel] freetype-web: New documentation regarding interfaces and services.

Hi, > (I converted many things already: https://github.com/madig/freetype-web > -- I > just didn't have the time to follow this up. The big missing part would be > integrating the design of FreeType.org) > I came across this thread on the mailing list while I was looking for some inspiration. I

[ft-devel] Static website themes for API reference

Hi all, I have converted around 4 pages of the API reference docs to markdown (thanks to Pandoc and some manual tweaking), to demonstrate how it will look with different themes. I have currently used MkDocs as the static website generator. The three available themes are

Re: [ft-devel] Static website themes for API reference

> > 1) MkDocs Default: >> https://nikramakrishnan.github.io/freetype-site/mkdocs/ >> > . I don't like the background, but I guess this is of no importance > right now. > MkDocs themes can be modified for the most part. I believe changing the background will not be very hard. > . A JavaScript b

Re: [ft-devel] Conversions and Branch on Repository

> The last commit seems to be broken in some places, line like this are > gone: > /* #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING */ > Thanks for pointing this out! Please check the attached patch. This has now been fixed (changes to docconverter pushed to GitHub). -- Nikhil define_lines_patc

Re: [ft-devel] Regarding FT_FACE_FLAG_FAST_GLYPHS

Hi, > I found that for the bdf driver in `bdfdrivr.c` the > `FT_FACE_FLAG_FAST_GLYPHS` flag is active for face_flags. But in > `freetype.h` it has been stated as `THIS FLAG IS DEPRECATED. DO NOT USE OR > TEST IT`. > I also found this flag in `src/pcf/pcfread.c.' Maybe this can be removed too?

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

Hi all, * 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'... > Parth, please

[ft-devel] Markdown generated with docmaker, and website

Hi all, I have been working on generating markdown by modifying docmaker, The generated site with Material theme is available at https://nikramakrishnan.github.io/freetype-site/ft2-toc/ (Please note that only General Remarks and Core API sections are available for now). All the generated markdo

Re: [ft-devel] Markdown generated with docmaker, and website

> * If you are going to update `docmaker', please add the time zone to > the `generated on' entry – otherwise the specification of a time is > completely useless :-) > I will change the time to UTC+00:00. After this change, the text would look like: "generated on Fri Jun 8 12:49:36 2018 UTC"

Re: [ft-devel] Markdown generated with docmaker, and website

> Looks great! Just a minor suggestion, I think it might be good to have > the index page get less columns as the page width shrinks, it gets > pretty hard to read when the aspect ratio is tall. > Working on this! I will probably reduce it to a single column on zoomed in/smaller displays. -- Ni

[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 outpu

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 later

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 expe

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’. No

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 i

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, a

Re: [ft-devel] convert `@Foo:' to `@foo:'

Hi, Nikhil, > > > I've just noted that we use both `@Foo:' and `@foo:' tags in the > header files. For consistency, please add a regex to your conversion > script to change them all to `@foo:'. > Should I change the whole string to lowercase? Doing that will also change stuff like `@FuncType' to

[ft-devel] Browsing API docs locally, and other updates

Hi all, I was looking at how browsing the docs locally would work. With the current configuration, running `make refdoc` with markdown docs will produce the following tree in the `docs/reference' directory: │ .gitignore │ mkdocs.yml │ README │ ├───markdown │ │ ft2-auto_hinter.md │ │

Re: [ft-devel] Browsing API docs locally, and other updates

> Although I can change links in the docs to point to index.html, the > navigation of the current theme I'm using (material) redirects *only* to > the > directory URL (I have filed a bug report for this). > Oops, just realized that the bug was in siteconfig.py

Re: [ft-devel] Browsing API docs locally, and other updates

> They already have support for that. Using 'mkdocs serve' command you can > browse website locally. > 'mkdocs serve' is used to browse the docs on a local server temporarily, this is essentially a developer option that should not be used otherwise. We need a static website that can be accessed fr

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 w

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

> 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

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 https://l

[ft-devel] Theme designs for the FreeType Website

Hi all, I am looking at different themes for the rest of the website. I have seen some nice Jekyll, MkDocs and other themes would like to share them. 1. Documentation Theme (Jekyll) Link - http://idratherbewriting.com/documentation-theme-jekyll/ This is the same theme being currently u

Re: [ft-devel] Theme designs for the FreeType Website

Hi all, I have converted and incorporated most of the website to the documentation theme. It is available at: https://www.dxdy.ooo/freetype-web-jekyll/ This is by no means complete or perfect. Many pages are merged, and some are missing. This is only a 'preview' of how the website will look. P

Re: [ft-devel] Theme designs for the FreeType Website

> > >> I have converted and incorporated most of the website to the > >> documentation theme. It is available at: > >> > >> https://www.dxdy.ooo/freetype-web-jekyll/ > > Thanks, looks good! Some comments, doing a direct comparison to > `freetype.org'. > > * Please increase the default font size

Re: [ft-devel] Theme designs for the FreeType Website

> > >> >> https://www.dxdy.ooo/freetype-web-jekyll/ > >> > >> * Please increase the default font size. > > > > Done. Size increased to CSS 'large'. [...] > > Thanks. Can I view this? The above link doesn't have the changes > yet. > I pushed this along with the other changes, and I see them l

Re: [ft-devel] Theme designs for the FreeType Website

> > > I pushed this along with the other changes, and I see them live. Do > > you see the serif font? > > Nope. Reloading the page > > https://www.dxdy.ooo/freetype-web-jekyll/ > > doesn't show any change. > > Trying on multiple devices, I see the changes. Maybe something to do with browser cac

Re: [ft-devel] Theme designs for the FreeType Website

> > I’m only loosely following this thread, but one thing: I have to > click two times in the nav bar to get somewhere. Headers like License > and Downloads house only one item each. I’d almost make them have no > items or expand the top level by default. > Yes, I feel the same. The theme does not

Re: [ft-devel] Theme designs for the FreeType Website

> * I'm quite fond of the FreeType logo integrated into the top bar, and > I would like to have this somehow retained. Right now, the top > looks like zillions of other blogs... Honestly, I would even like > to retain the color changes of the top bar depending on the nesting > depth, but

Re: [ft-devel] Theme designs for the FreeType Website

> > I have changed the topbar to integrate the FreeType logo and colors. > > Please have a look and let me know what you think! > > Nice! I suggest that you remove the string `The FreeType Project' in > the top left corner, only putting the house symbol there – or maybe > integrating the house sym

Re: [ft-devel] Theme designs for the FreeType Website

> Mhmm, I think this is suboptimal; it doesn't look appealing to me. I > suggest to drop it completely – we have a `Home' button already. > Done. > Please check if everything looks fine, and if any changes are > > required. > > Looks good, with some exceptions. > > * The font size for code block

Re: [ft-devel] Theme designs for the FreeType Website

> > (Aside from increasing code block font size, you could also use > https://www.google.com/get/noto/#mono-mono for all code to see if it > blends in better than Courier New and the rest of the font stack) I don't see a Google Fonts service for Noto mono. Using Roboto Mono instead. I believe it

Re: [ft-devel] Theme designs for the FreeType Website

> I think this is a bit too large – it should be possible to have > approx. 80 characters per line, as most code snippets have. > Tweaked it a little bit. Fits 80 characters comfortably now. -- Nikhil ___ Freetype-devel mailing list Freetype-devel@non

Re: [ft-devel] Theme designs for the FreeType Website

> Size is fine now, thanks! Maybe we can use a nice web font for code > snippets also? Courier is soo ugly... I like CMU typewriter (IMHO the > best font from the Computer Modern family), but I don't know whether > there is a font server for easy access. > I found CMU Typewriter on fontlibrary.

Re: [ft-devel] Theme designs for the FreeType Website

Hi all, I've added the remaining parts of the website (documentation), and the new API reference (generated using docwriter). Please have a look at the website, and let me know if there are any issues. The website is at https://www.dxdy.ooo/freetype-web-jekyll/index.html The API reference is at

[ft-devel] Updates to Docwriter: Logging, testing, linting

Hi all, I've been working on improving docwriter's maintainability. These are the changes made in the past few days: * Docwriter now uses the standard logging library of python, instead of printing directly to stderr. This gives greater control over messages and their formatting. * Docwriter can

Re: [ft-devel] Updates to Docwriter: Logging, testing, linting

> Hi Nikhil, > I had a superficial look: > > * I still recommend an autoformatter because it eliminates a certain class > of error: the formatting nit before merging a PR. Otherwise, you end up > micromanaging e.g. spaced () ( > https://github.com/nikramakrishnan/freetype-docwriter/blob/master/cont

Re: [ft-devel] Updates to Docwriter: Logging, testing, linting

> There likely isn’t one because `foo( bar )` is discouraged in Python-land: > https://www.python.org/dev/peps/pep-0008/#pet-peeves. If it’s okay with > Werner, I strongly suggest going with idiomatic Python style instead of > carrying over the C style. The formatter Black will do everything you ne

Re: [ft-devel] External link modified

> There is a link to [1] in the last section on [2] (labeled "dropout > control") which is no longer available. > This might be the new link: https://docs.microsoft.com/en-us/typography/opentype/spec/ttch01#the-scan-converter I've also noticed 404's on some other links to Microsoft docs. Here's

Re: [ft-devel] Theme designs for the FreeType Website

> Is there a particular reason why the left navigation panel is > horizontally so small? On the attached image you can see, for > example, > > The v40 > TrueType > interpreter > mode > > i.e., four lines for a single item... > > Maybe it helps to make the panel wider and/or reduce the font

Re: [ft-devel] Theme designs for the FreeType Website

> I feel harmonizing the theme colors of the API reference to match > the remaining site and changing the fonts to serif should make them > look more similar. > Changed fonts to serif, and theme to green. See at: https://www.dxdy.ooo/freetype-web-jekyll/docs/reference/ft2-toc Let me know what you

Re: [ft-devel] actually converting FreeType documentation to markdown

Hi, how shall we do the conversion of the API documentation (in the header > files) to markdown? What steps do you recommend? > Once we convert the documentation to markdown, it will become incompatible with the current docmaker. I suggest the following: 1. Create a separate branch and push doc

Re: [ft-devel] Bad index layout in API documentation

Hi, have a look at the attached image of > > https://www.dxdy.ooo/freetype-web-jekyll/docs/reference/ft2-index/ > > This is with Chrome 67 on my GNU/Linux box at a size of 100%. > > It seems that you have to change from three columns to two. Or maybe > only one column? And a navigation help fo

Re: [ft-devel] Collision between middle and right column in API

> please have a look at > > > https://www.dxdy.ooo/freetype-web-jekyll/docs/reference/ft2-properties/index.html > > and check how the documentation of FT_AUTOHINTER_SCRIPT_XXX gets > rendered. On my box, the tables clash badly with the right column, > see attached image. > > It seems we need a for

Re: [ft-devel] Bad index layout in API documentation

> > I'll change it to maybe a single column and add headings for > > starting letters, so they show up as navigation in the right column. > > This should also simplify the markdown file for the index. > > Thanks in advance. > This is done, please check https://www.dxdy.ooo/freetype-web-jekyll/docs

Re: [ft-devel] Collision between middle and right column in API

> I've changed the code to format all tables with code sequences in them like > you mention above. I'll update the website soon. > This is fixed now. Please have a look at https://www.dxdy.ooo/freetype-web-jekyll/docs/reference/ft2-properties/index.html#ft_autohinter_script_xxx This format will

Re: [ft-devel] Bad index layout in API documentation

> Very nice, thanks! Note that all links currently fail (it misses a > `reference' subdirectory in the link). > Oops, this is fixed now. -- Nikhil ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/fre

[ft-devel] Integrating Docwriter into FreeType

Hi all, I have started integrating docwriter in the savannah repository. It is available in the 'GSoC-2018-nikhil' branch. It would be great if it could be tested on a few different system configurations so that we can fix any issues before merging. I have added the required commands to make targ

Re: [ft-devel] Integrating Docwriter into FreeType

> Hmm. `make refdoc' is not a target that is to be called by Joe User. > It was always handled specially, i.e., it was assumed, for example, > that Python is available, without testing for its existence. > True. I'm not sure if we should shift the responsibility of creating a virtualenv to the us

Re: [ft-devel] Integrating Docwriter into FreeType

> > > In any case, we must ensure `pip' is available. > > Yes. But packages should *not* be installed by the script but by the > user. I think something like the following might work. > > 1. Check whether all needed modules are available, ideally using a >simple solution that doesn't need `pi

Re: [ft-devel] Integrating Docwriter into FreeType

> In that case, how about punting on the issue entirely and instead > publishing docwriter on PyPI and letting people pip it from there? You just > test for its availability in PATH and tell people what to do to get it > otherwise. Then you have full control over whether you want to install it > gl

Re: [ft-devel] `make refdoc-venv' fails

> > Alternatively instead of sourcing the venv, the refdoc target can > call the docwriter.py script using the python interpreter that is > inside the virtual environment, since you know the exact path to it > as refdoc-venv has created it. > Thanks! I'm waiting for Nikhil to fix that :-) > Done

Re: [ft-devel] virtualenv in Python2 vs. Python3

> what do you think of making `refdoc-venv' a target for Python3, adding > another target `refdoc-virtualenv' for Python2? > Different targets because Python 3 ships with venv? The problem is, some Linux distributions are not distributing venv with Py3 (Ubuntu for example), so it makes no differen

Re: [ft-devel] Integrating Docwriter into FreeType

> OK. Let's try the following route. > > (0) Make docwriter a PyPI package. > I do not have experience with packaging and publishing libraries to pip. I tried doing it yesterday but got a bunch of import errors, so I might need some help with this one. > (1) Add a check for (a) `python', (b) `p

Re: [ft-devel] Integrating Docwriter into FreeType

> IMO if “docwriter” is only used by freetype and for freetype there is no > reason to publish it on PyPI, which is more meant for reusable libraries as > opposed to applications. > Well, this is open for discussion, because I don't think all of the more than 140,000 packages on pip are reusable.

Re: [ft-devel] Integrating Docwriter into FreeType

> You can follow https://packaging.python.org/ for that. > Thanks. To make docwriter a package, I had to move some things around, change some code (mostly import statements) and add a few more py files. I could finally produce a working package which can be invoked as `python -m docwriter` from w

Re: [ft-devel] Integrating Docwriter into FreeType

> Keep in mind that you need to tell tox to cd into tests/ before running > pytest, otherwise you’re testing the source directory instead of the > installed package. > > https://tox.readthedocs.io/en/latest/config.html#confval-changedir=path I'm running the tests on the source directory using `py

Re: [ft-devel] Integrating Docwriter into FreeType

> This is a bit tricky in Python, see > https://blog.ionelmc.ro/2014/05/25/python-packaging/#the-structure. > > Basically, tox and therefore pytest is run from the project root > directory, which happens to have the docwriter module-directory. Python by > default has the current directory in the im

Re: [ft-devel] Integrating Docwriter into FreeType

> I think that helped you find a bug in your packaging :) The tests should > find a docwriter module because that’s what tox installs in the testenv. > Look into what is actually getting installed deep in .tox. > Why would tox 'install' the package inside the testenv? I have not specifically told

Re: [ft-devel] Integrating Docwriter into FreeType

Let's move to the next step > OK. Let's try the following route. > > (0) Make docwriter a PyPI package. > This is mostly done now, and I'll be merging to master shortly. Please also suggest a name for the package if 'docwriter' is too generic. > (1) Add a check for (a) `python', (b) `pip', an

Re: [ft-devel] Integrating Docwriter into FreeType

> It basically runs "pip install ." or "python setup.py install", so it > does whatever setup.py does. > Ah, after searching a little bit I realized I had added 'skipdist = true' because docwriter wasn't a package before. Added now, and tests now done in the tests/ directory. Thanks! -- Nikhil

Re: [ft-devel] Integrating Docwriter into FreeType

> Well, `docwriter' isn't taken yet on pypi.org, and you wrote that you > are probably extending it to a more generic package, so I think you > should stay with that name. > OK. > The file to be modified is `builds/unix/configure.raw', which is a > shell script that (a) gets processed to `builds

Re: [ft-devel] Integrating Docwriter into FreeType

I'm also considering shifting `docwriter' to FreeType's GitHub account, so that we can auto-deploy to pip from there, and future maintenance will be easy. Thoughts? -- Nikhil ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu

Re: [ft-devel] Problem with `make refdoc'

Hi, running > > pip install --user docwriter > > was successful! However, if I now say > > make refdoc > > I get > > $ make refdoc > Running docwriter... > python -m docwriter \ [...] > > /usr/bin/python: No module named docwriter > > Reason is that my `pip' is actually `pip3', while

Re: [ft-devel] Integrating Docwriter into FreeType

> Ah, here should be > > checking for `docwriter' Python module... no > > I missed that. So the code should be something like > > have_docwriter=no > (...) > Thanks, changes applied. > > Also, is there a way to store the $PYTHON variable (python/python2/ > > python3) so that I can use i

Re: [ft-devel] Integrating Docwriter into FreeType

> Yes, if `docwriter' becomes a separate package, it should be moved to > a separate git repository for simplicity, and `freetype/docwriter.git' > on github seems like a logical choice. Recently something similar was > done for the fuzzer stuff. > Docwriter is now available on GitHub at https:

Re: [ft-devel] Integrating Docwriter into FreeType

> I'll be archiving my own repository (nikramakrishnan/docwriter) shortly, > and > adding auto-deploy (to PyPI) for tagged commits. > This is now done. --- I just realized that I have to make changes to `Jamfile' for the action `refdoc'. The code used there is: actions RefDoc { python

Re: [ft-devel] (no subject)

> attached you can find an Elisp script in disguise which calls Emacs > with itself. It will do the paragraph formatting after executing > `markify.py' as discussed. > > I've commented the script extensively; hopefully, it makes you > understand the Elisp code a little bit :-) > Thank you for the

Re: [ft-devel] (no subject)

> Ah, this is the result of Emacs's `adaptive fill mode' that > automatically determines the fill prefix of paragraphs. Setting the > corresponding regexp explicitly fixes this. Attached is a patch – it > fixes some more places. > Great, this fixes it. Meanwhile, I had a look at the complete di

[ft-devel] Docwriter update: Docwriter 1.0 is out!

Hi all, MkDocs 1.0 was just released and the directory structure was finally fixed! This means that all links are now `docs/reference/page.html' instead of `docs/reference/page/index.html'. With this, the docs are now organized nicely in a single directory. I've released docwriter 1.0 with the re

Re: [ft-devel] Love the new docs!

> A quick word of appreciation: using Nikhil's preview for browsing the docs > since yesterday and man that's fast + convenient! No need for Google > or > browser bookmarks or Ctrl+F or tabbing or ... very well done, I love it! :) > That's great to know! I can't wait for it to go live :-)

Re: [ft-devel] `make refdoc' fails if builddir != srcdir

> The title says it all. > > $ mkdir freetype2.compiled > $ cd freetype2.compiled > (...) > > Reason of the failure is that there isn't a `markdown' subdirectory. > To have a functional `reference' directory tree I thus suggest that > the files and directories from srcdir's `reference' tree get

Re: [ft-devel] converting to Markdown

> > Everything looks fine. Please apply to master! > Oops, totally forgot about adding a changelog entry. Thanks! -- Nikhil > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] `make refdoc' fails if builddir != srcdir

> LGTM, thanks. Please commit, with ChangeLog entry :-) > Thanks for testing, pushed! -- Nikhil ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] Documentation guidelines file

Hi, I've attached the `docs/DOCUMENTATION' file (from the draft work at https://github.com/nikramakrishnan/freetype-docs/wiki/Documentation-Guidelines-for-The-FreeType-Project ). This should cover everything needed to understand the basics and the markdown formatting of the docs. A few things, su

Re: [ft-devel] Documentation guidelines file

> > Thanks, very informative! :) The only thing missing (if I haven't > > missed it) is the fact that apostrophes are used to refer to other > > parameters of the same function ... eg: > > > > ``` > > /** ... > >* ... > >* @description: > >* Uses 'a' to meep 'b'. > >* ... >

Re: [ft-devel] Documentation guidelines file

> > I'm not sure what cases this covers. Can you provide an example? > > For example, look at > > > https://www.dxdy.ooo/freetype-web-jekyll/docs/reference/ft2-base_interface.html#ft_charmap > > The links `FT_Get_Char_Index' or `FT_Load_Char' point to functions > (i.e., defined with `@function:' an

Re: [ft-devel] Documentation guidelines file

> >> BTW, I see > >> > >> face- > >> >num_charmaps > >> > >> i.e., a line break after the `-' (within ...). This > >> is bad. Can this be fixed in CSS? > > > > I'm not able to reproduce this at any zoom level, can you send a > > screenshot? > > Attached is another example from the `note' sect

Re: [ft-devel] Documentation guidelines file

> > Ah, this is only reproducible on Chrome. Firefox ignores word break > > rules. A little searching and experimenting gave me the answer. > > Should be fixed now! > > Thanks a lot! Have you already pushed the changes to the repository? > Not yet, will do it today. Oh, and is there anything l

Re: [ft-devel] Documentation guidelines file

> >> Have you already pushed the changes to the repository? > > > > Not yet, will do it today. > > Thanks. Just curious: Where can I find the fix for @foo to be > displayed with ...? > Just released in docwriter 1.0.2. > > Oh, and is there anything left to add in the `DOCUMENTATION' file? > > I

  1   2   >