Hi all,
I want to quickly point to existing resources that could be of any help:
I think this was already mentioned in one of the threads: This repository
https://github.com/nikramakrishnan/freetype-web-jekyll
(and the published site at
https://nikramakrishnan.github.io/freetype-web-jekyll/)
Hi Alexei,
I don't know if we use it anywhere yet, but markdown links should work
correctly.
https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/docs/DOCGUIDE#L216
Do let me know if this is not the case.
Thanks,
Nikhil
On Sat, May 1, 2021 at 5:48 PM Alexei Podtelezhnikov wrote:
> > Maybe that could be used as a starting point?
>
> Starting point for what?
>
This was in reference to Werner's suggestion to improve the website. When
we migrated the documentation to markdown, I had done a markdown version
for the contents of freetype.org as well (should still be live at
Quick note: We do have a markdown version of the website from a few years
ago that we never actually transitioned to. Maybe that could be used as a
starting point?
Nikhil
Hello Anuj,
> > Does your computer have sufficient storage to install "Windows Subsystem
> > for Linux" ?
>
> I do have linux installed alongside windows (dual boot). But I mostly use
> Linux for testing cross platform applications or writing code specific to
> Linux.
> It's just that I have
> No problem! Thanks again for looking into the issue – I would be glad
> if you could eventually implement a fix, but this is no longer urgent.
> For the moment, I will add a sentence that the search field doesn't
> work for locally installed documentation.
Thanks. I'll look into possible fixes
> This is unfortunate. Is there something less invasive available?
I did a quick search, and came across this pull request in the mkdocs
repository:
https://github.com/mkdocs/mkdocs/pull/1805
I quickly tested this:
* Create the file `docs/markdown/javascript/fetch_shim.js`, adding the
I forgot to add that `mkdocs serve` builds the site from the source
markdown files each time, so those too will have to be retained in the
distribution.
Nikhil
Hello Werner,
> The last step fails with
>
> Config file '.../docs/mkdocs.yml' does not exist.
>
> Note that `mkdocs.yml` gets explicitly removed while calling `make
> dist` (see `builds/toplevel.mk`).
`mkdocs serve` requires the file `mkdocs.yml` to generate the site and
start up the server.
A quick tip: If search does not work for you while browsing the docs
locally, try running `mkdocs serve' (or `python3 -m mkdocs serve') in
the `docs/' directory (after `make refdoc'). This serves the site on a
local server, providing a more website-like experience.
Hello Werner,
> if `srcdir` == `builddir`, the directory
>
> $srcdir/docs/reference/images
>
> exists after executing `./configure && make && make refdoc`, and the
> 'FT' icon is properly displayed. However, if `srcdir` != `builddir`,
> the directory is missing, and the icon doesn't get
Hi all,
Docwriter 1.3 has been released. This release, along with commit
1fd3148 includes important changes to support Python >= 3.5 and drop
support for older versions.
Python versions < 3.5 have reached end-of-life, and the sunset date
for Python 2 was January 1st, 2020.
To be able to use
> I've just integrated your woff2 stuff into FreeType. Thanks again for
> working on this!
I had a great time working on this! Thanks for fixing formatting and
adding the comments.
--
Nikhil
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
> With my quick testing of some woff2 fonts: everything looks fine,
> thanks! Please prepare your report.
Thanks for testing! I have prepared a report and it is available at
https://gist.github.com/nikramakrishnan/f88f3bae3cd2f0ba06d20ab3e0c74fb3
Please let me know if I should add anything.
Hi,
> Some minor comments to the code.
> (...)
Thanks for reviewing. Fixed now :-)
--
Nikhil
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Hi folks,
I have improved trace comments and added functions to handle most
(hopefully all) cases from the WOFF2 recommendation. Please test!
Nikhil
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
> Is this only useful for WOFF2? Or, can it be productively utilized by
> TTC in general?
Sorry I missed this mail. Right now this is only useful for WOFF2. In
the future, if we have another sfnt-wrapper format that supports TTCs,
this can be generalized.
--
Nikhil
> > So are you suggesting that `sfwoff2.c' directly output the total
> > number of faces and named instances (if the index is < 0) and exit
> > with error so that FT_Open_Face does not try to read and output this
> > data again?
>
> In case this makes life simpler, please do it! The alternative
> What am I missing?
My main concern is that *after* `woff2_open_font' returns,
`sfnt_init_face' attempts to read the TTC header and extract
information about the total number of faces, and stores this in
`face->num_faces', which will override the value stored by
`woff2_open_font'.
--
Nikhil
>
> This means that you can quickly extract the number of TTC subfonts,
> right?
Yes, this value is also stored in `WOFF2_HeaderRec' as `num_fonts'.
>
> > One solution is to load all the faces in the WOFF2 and write all
> > tables along with the TTC header. This may slow down the process if
>
> Hmm. The functionality of negative `face_index' values as document
> in the description of `FT_Open_Face' must work for WOFF2, too. So, to
> get the number of faces in a TTC, you have to read the TTC header.
`woff2_open_font' reads the WOFF2 TTC header and uses that information to
get tables
Hi all,
An update on the progress of WOFF2 support:
With commit af7d296 (in branch `GSoC-2019-nikhil'), we can now quite
efficiently convert a WOFF2 to an SFNT font, which can then be
rendered by FreeType.
Some points:
(1) If the WOFF2 is a TTC, only the requested face is loaded. So,
instead
> `FT_Stream_OpenMemory' is be the right function. After calling this,
> you should use `FT_Stream_EnterFrame' and proceed as usual.
This is working now. I think the issue was due to some trivial error I
made while creating the stream and passing it to other functions.
However, could you please
Hi,
I have now added code to uncompress the Brotli-compressed stream.
Right now, I'm allocating the required memory for the stream, and
storing the output in an FT_Byte array (`uncompressed_buf'). How do I
create an `FT_Stream' from this so that I can read it using the
`FT_READ_XXX' macros? I
Hi,
> Moazin, Nikhil, would one of you be able to do that? Of course after
> the GSoC, or in case you have too much time :-)
Although I have no experience with zlib either, I'll be happy to help
out with this after summer, if I can find the time :-)
--
Nikhil
Hi,
I have added Brotli as a dependency with commit
8e05ab3e2ebf9d90b6015cb2aa7e789517b293e6. This works on my setup after
installing Brotli and running `sh autogen.sh', `./configure' in the
freetype2 directory. I'm also now able to include `brotli/decode.h' in
`sfwoff2.c'. Is there anything else
> What do you mean with `access'? `sfnt_open_font' fills up the array
> with all header offsets; it thus doesn't need a face index.
But the whole process of uncompressing a WOFF2 will take place in
`sfwoff2.c' (woff2_open_font), which is being called from
`sfnt_font_open'. If the function is
> A single font from a TTC collection has no references to the TTC as a
> whole. So yes, you can completely hide the fact that you are
> processing a TTC.
Great, so I can load only the requested font.
> > Do these `individual' streams function identically to a full `TTC'
> > stream?
This was
Hi,
> > * For TTC fonts, the `Collection Directory' specifies the index of
> > tables that are part of each font in the collection. The
> > `face_index' parameter in `FT_New_Face' specifies which face to
> > load, so does that mean I can use that to directly extract and
> > load only
> > * Is the code, in general, acceptable? Am I using the FT_* typedefs
> > and macros correctly?
>
> After a quick inspection, everything looks good, thanks! Don't worry
> too much, you will get a better feeling for that stuff soon :-)
Great, thanks! It does get better over time :-)
--
> > Do I have to decompress each
> > table and load the whole collection as an SFNT? I'm not sure...
>
> WOFF1 compresses each table, WOFF2 compresses the entire stream.
> https://www.w3.org/TR/WOFF2/#FileStructure
> Do you have a choice?
Oh, this totally slipped my mind! So after decompressing
> Regarding testing, you can try the following:
>
> 1. otsanitizer has a test data directory with "good" and "bad" fonts:
> https://github.com/khaledhosny/ots. Remember to compile your copy of
> the library with the `-fsanitize=address,undefined
> -fno-sanitize-recover` compiler switches so that
Hi folks,
I have implemented functionality to read the WOFF2 header, table
directory and collection directory (if the font is a TTC), including
most of the checks (given in the specification) in `sfwoff2.c' on the
`GSoC-2019-nikhil' branch. It would be *great* if you could review
(and also test
Werner, Moazin,
Thanks for your suggestions!
> The `FT_READ_XXX' macros use implicit `stream' and `error'
> variables.
>
> `FT_READ_XXX' can be controlled with `FT_STREAM_SEEK' and
> `FT_STREAM_POS'. They use the full machinery to check whether a
> read is valid.
Using `FT_READ_XXX'
Hi,
I have added code (on the GSoC-2019-nikhil branch) to read the WOFF2
header, and I'm using FT_FRAME_START and FT_FRAME_END along with
FT_FRAME_* in this case (fixed size).
> You have to split the handling into fixed-size and variable-size
> parts. For the fixed-size stuff you can use
Hello Moazin,
> This enables both `gzip' and `zlib' decoding with automatic header detection.
> Solving my problem.
It's great that the same function can be used to decode both!
> This solves it for me and I HOPE this won't cause cause any previous code
> relying on `FT_Gzip_Uncompress' to
Hi,
I have been going through the WOFF2 specifications, and there a lot of
optional fields in various tables.
For example, the header size is fixed (48 bytes), but the table
directory (https://www.w3.org/TR/WOFF2/#table_dir_format) has 2
optional fields, `tag' and `transformLength'. In addition,
Hi Armin,
Great guide! It's short but super-informative; exactly what people
should know (and can always review) while writing code in FreeType.
--
Nikhil
P.S.: s/MarkDown/Markdown
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Hi,
> Armin, Nikhil, wasn't there a plan to set up a FreeType mirror? Could
> you do that?
Here are some possible ways we could do this:
1. Set up a server side post-receive hook so that all commits are
pushed to the mirror immediately.
2. Set up a cron job server side to push commits at a
Hi,
> I think so. The metadata were in WOFF1 as well. They contain information
> usually packed into the 'name' table, but perhaps more structured. It is
> optional and can be added eventually.
OK.
A question related to the compression library:
Assuming the Brotli library from Google is
Hi all,
First of all, thank you for the great project description, the links
provided are quite helpful!
I read more about the project, and it got me quite interested in the
WOFF2 format and its compression. I have a few observations:
* The structure of WOFF2 is quite similar to WOFF fonts
Hi,
> It was a deliberate change, but hmm. Nikhil, do you have a
> suggestion?
>
Well, a simple fix would be to move all files from `docs/reference/site'
to `docs/reference'. The `site/' directory was added to the path only
because of the other files docwriter generates. These are not
required
Hi,
> As far as I can see, the stuff in the
> directory `docs/reference/markdown' is the result of an intermediate
> step and can thus be completely omitted, right? The same appears to
> be true for file `mkdocs.yml'.
>
Yes, the files in `docs/reference/site' are sufficient for the
>
> > Is there a timeframe yet when the new documentation will be
> > released? I use Nikhil's preview whenever I dive into FreeType but
> > I think everyone would really benefit from having access to it,
> > spec. to the search function :)
>
> As soon as the next FreeType version gets released,
> >> I've just done some minor improvements in
> >>
> >>
> https://github.com/nikramakrishnan/freetype-docs/wiki/Documentation-Guidelines-for-The-FreeType-Project
> >
> > Thanks! Should we add this file in the `docs' directory?
>
> Yes, please add. What do you think of calling this 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?
>
>
> > 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
> >> 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'
> > 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:'
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,
> 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
>
> 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
> 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
> 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 :-)
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
> 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
> 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
> 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
{
> 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
> 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
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',
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
> 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
> 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!
--
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',
> 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
> 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
> 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
> 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
> 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.
> 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)
> 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
>
> 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 :-)
>
> 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
>
>
> > 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
> 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
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
> 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
> 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
> > 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
> 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
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
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
> 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
> 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
> 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
> 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
> 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 () (
>
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
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
> 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
> 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
>
> (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
> 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
> > 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
> * 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
>
> 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
>
> > 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
>
> >> >> 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
>
> >> 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
1 - 100 of 143 matches
Mail list logo
