Re: [ft-devel] COLR/CPAL
> Looks to me like FT_HAS_COLOR still returns false for COLR/CPAL > fonts. Any idea? How do you come to this impression? There is the following code in `sfobjs.c' around line 1405: if ( face->sbit_table_type == TT_SBIT_TABLE_TYPE_CBLC || face->sbit_table_type == TT_SBIT_TABLE_TYPE_SBIX || face->colr ) flags |= FT_FACE_FLAG_COLOR; /* color glyphs */ For me it seems to work. Do you have a counterexample? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Updates to Docwriter: Logging, testing, linting
> There is no harm in everything looking the same; on the contrary, > new people familiar with other codebases can contribute more easily > because stuff looks the same — and since it’s automated, no PR ever > gets round-tripped because of some formatting nitpick. This is a very simplistic approach that doesn't fit all situations IMHO. > In fact, I can’t think of a concrete reason why a codebase should be > allowed to look different from other codebases. So tell me why Python itself allows a consistent but arbitrary number of spaces as indentation? > The dictator in this case is really PEP 8, black is just its > henchman. This approach is quite pythonic. In PEP 8, value 4 for indentation is like the parallel postulate: it is completely isolated from all other recommendations... Given that PEP 8 recommends a line length of 79 characters, it would be easier to obey this limitation if indentation is small. Whatever :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Updates to Docwriter: Logging, testing, linting
> I strongly disagree. Within a project everything must be consistent, > no question. However, I don't see any reason that *all* projects must > look the same, with a single person (or a small team) being the > formatting dictator. There is no harm in everything looking the same; on the contrary, new people familiar with other codebases can contribute more easily because stuff looks the same — and since it’s automated, no PR ever gets round-tripped because of some formatting nitpick. In fact, I can’t think of a concrete reason why a codebase should be allowed to look different from other codebases. The dictator in this case is really PEP 8, black is just its henchman. This approach is quite pythonic. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Updates to Docwriter: Logging, testing, linting
> I love it. Configurability is the enemy of consistency. I strongly disagree. Within a project everything must be consistent, no question. However, I don't see any reason that *all* projects must look the same, with a single person (or a small team) being the formatting dictator. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Updates to Docwriter: Logging, testing, linting
I love it. Configurability is the enemy of consistency. I get bouts of "E" when I have to look at other people's formatting preferences. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Updates to Docwriter: Logging, testing, linting
> Uh oh. Black enforces 4 spaces for indentation. Honestly spoken, this would be an immediate reason for me to not use this tool, were I a Python programmer. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Updates to Docwriter: Logging, testing, linting
Uh oh. Black enforces 4 spaces for indentation. Black is the formatter with the most momentum right now. Yapf is more configurable but according to the black author not as consistent, which is why he wrote black in the first place. Good luck ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Updates to Docwriter: Logging, testing, linting
> I've applied black to docwriter.py in the latest commit where I > implement cli using argparse. It looks quite readable, IMHO. Indeed! > https://github.com/nikramakrishnan/freetype-docwriter/blob/f6f9dd07d89fa72bb5f17d563011e0790f2324a1/docwriter.py Minor nit: s/Setup the logger./Set up the logger./ Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Updates to Docwriter: Logging, testing, linting
> [...] `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 need for that. BTW, I would like to have an indentation level of two spaces instead of four – I see no reason to waste so much horizontal space, and four spaces don't really increase readability IMHO. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Updates to Docwriter: Logging, testing, linting
Hello Nikhil! > I would really like to use a formatting tool like yapf, but the only > problem is that it doesn't have a configuration/option for the > > foo( bar ) > > format (space in brackets). No need to retain that. You are going to completely rewrite the tool, so I don't mind if you change such code to `foo(bar)' in case you prefer that. What I want, however, is a mainly vertical code flow and lines not longer than 78 characters if possible. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Updates to Docwriter: Logging, testing, linting
> You could also run it via tox on Travis: > https://github.com/fonttools/ufoLib2/blob/master/tox.ini > > Tox seemed too much for this module, and Travis does the multi-version checks > anyway. but I'll consider adding it. The prime advantage of using tox is that you can just type `tox` on your local machine _and_ on Travis and the testing procedure will be the same (ufoLib2 uses it in a way that pre-commit is run on each invocation, too). It’s not a must, of course. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Need clarification on font cutoff
Thanks. Regards, Madan On Sat, Jul 14, 2018 at 6:40 PM, Alexei Podtelezhnikov wrote: > > Could you please share the reason of why extra dots/lines came in older > versions of freetype. > > In 2.8.1 we improved LCD padding. See http://git.savannah.gnu. > org/cgit/freetype/freetype2.git/tree/docs/CHANGES > > Many programs got bitten by that: Firefox, Chrome and anyone who used > Skia. They worked around the change. I cannot call that a fix because they > continue to guesstimate the bitmap size even today they instead of asking > Freetype. We have everything to fix it properly now even for font atlassing > in GPU. > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 need > for that. > I've applied black to docwriter.py in the latest commit where I implement cli using argparse. It looks quite readable, IMHO. Of course, I'll only go ahead with this formatting style (PEP8 with line length 80) if Werner agrees. Here's the 'black' formatted version: https://github.com/nikramakrishnan/freetype-docwriter/blob/f6f9dd07d89fa72bb5f17d563011e0790f2324a1/docwriter.py > This is fixed. Module descriptions are in docstrings now. > > As I commented on GitHub, I recommend using > https://pypi.org/project/docformatter/ for formatting docstrings. > Yes, I'll add this, thanks. > In short: automate all the drudgery you can automate and you will increase > maintainability. > > > Speaking of automation, did I mention pre-commit yet? > https://pre-commit.com/, `pip install pre-commit`. > > It automates running Git hooks on your project on every commit. You can > e.g. automatically run black on the source, remove spurious line-end > whitespace, check YAML files and much more. > > You insert a file like > https://github.com/fonttools/ufoLib2/blob/master/.pre-commit-config.yaml > in your top-level and run `pre-commit install`. After that, every commit is > run through the gauntlet before being allowed to pass. Follow the repo URLs > to see available hooks to run. I personally like pyupgrade. This looks great, I'll check it out as soon as I can. > You could also run it via tox on Travis: > https://github.com/fonttools/ufoLib2/blob/master/tox.ini Tox seemed too much for this module, and Travis does the multi-version checks anyway. but I'll consider adding it. -- Nikhil ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Need clarification on font cutoff
> Could you please share the reason of why extra dots/lines came in older > versions of freetype. In 2.8.1 we improved LCD padding. See http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/docs/CHANGES Many programs got bitten by that: Firefox, Chrome and anyone who used Skia. They worked around the change. I cannot call that a fix because they continue to guesstimate the bitmap size even today they instead of asking Freetype. We have everything to fix it properly now even for font atlassing in GPU.___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Need clarification on font cutoff
Hi, I am not blaming, just trying to understand :). Could you please share the reason of why extra dots/lines came in older versions of freetype. Just I will think in same angle on our code what we could have done wrong in manipulation?. Thanks. Regards, Madan On Sat, Jul 14, 2018 at 6:12 PM, Alexei Podtelezhnikov wrote: > > > Basically, there is no difference. The bug might be either in > > FreeType or in your code, unveiled by a change in FreeType. I can't > > tell. > > Madana, > > We need you to git bisect the bug, unless you can tell us how to reproduce > it (share code and font, or steps using Freetype demo tools). There is no > other way around it. > > Looking at your edge artifacts, I can only speculate that your program > deviates from API and tries to be too smart with bitmap dimensions or > positions instead of just using what Freetype returns. You code is probably > almost always right so you tend to blame Freetype, which is natural but > wrong. > > Alexei ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Need clarification on font cutoff
> Basically, there is no difference. The bug might be either in > FreeType or in your code, unveiled by a change in FreeType. I can't > tell. Madana, We need you to git bisect the bug, unless you can tell us how to reproduce it (share code and font, or steps using Freetype demo tools). There is no other way around it. Looking at your edge artifacts, I can only speculate that your program deviates from API and tries to be too smart with bitmap dimensions or positions instead of just using what Freetype returns. You code is probably almost always right so you tend to blame Freetype, which is natural but wrong. Alexei ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Updates to Docwriter: Logging, testing, linting
> I would really like to use a formatting tool like yapf, but the only problem > is that it doesn't have a configuration/option for the foo( bar ) format > (space in brackets). I checked options from > https://github.com/google/yapf/blob/master/README.rst#knobs. Am I missing > something? 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 need for that. > This is fixed. Module descriptions are in docstrings now. As I commented on GitHub, I recommend using https://pypi.org/project/docformatter/ for formatting docstrings. In short: automate all the drudgery you can automate and you will increase maintainability. Speaking of automation, did I mention pre-commit yet? https://pre-commit.com/, `pip install pre-commit`. It automates running Git hooks on your project on every commit. You can e.g. automatically run black on the source, remove spurious line-end whitespace, check YAML files and much more. You insert a file like https://github.com/fonttools/ufoLib2/blob/master/.pre-commit-config.yaml in your top-level and run `pre-commit install`. After that, every commit is run through the gauntlet before being allowed to pass. Follow the repo URLs to see available hooks to run. I personally like pyupgrade. You could also run it via tox on Travis: https://github.com/fonttools/ufoLib2/blob/master/tox.ini ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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/content.py#L113) > and unspaced () ( > https://github.com/nikramakrishnan/freetype-docwriter/blob/master/content.py#L143 > ) > I would really like to use a formatting tool like yapf, but the only problem is that it doesn't have a configuration/option for the foo( bar ) format (space in brackets). I checked options from https://github.com/google/yapf/blob/master/README.rst#knobs. Am I missing something? > * I also suggest you keep to testing 2.7 and 3.6 or 3.7. Is there a > requirement for testing 3.4 and 3.5? > 3.7 is not supported on Travis CI yet. I'm testing 2.7, 3.5 and 3.6 now. > * In e.g. formatter.py, you duplicate the module docstring in the comment > above. This is redundant, I recommend writing everything important into the > docstring, as that is accessible in Python. > This is fixed. Module descriptions are in docstrings now. * Any reason for the "# eof“ comments at the bottom? > This was already present in docmaker, and other source files in the library also mark eofs, so I figured this was somewhat important. > * I suggest you fix the `import *` statements and instead be explicit. > This is fixed, thanks. > * You might want to use the argparse module instead of getopt, that should > simplify docwriter.py significantly. > https://docs.python.org/3/howto/argparse.html. Writing your own usage() > is inelegant. > I was actually thinking about replacing getopt because of the increasing work required to maintain the usage() function. Working on this right now. It is indeed much simpler to work with argparse. As a very general aside, I suggest you avoid doing anything other than > assigning arguments in __init__ and instead use @classmethod constructors > for initializing everything you need for a class. See e.g. > http://as.ynchrono.us/2014/12/asynchronous-object-initialization.html. > Using the new @dataclass or the attrs module will nudge you into this > direction by writing __init__ for you. I’m not saying you should do this > right now, as this requires re-designing most classes. But take it as a > suggestion for future work. The general pattern would be: [...] > I'll have a look at this, thanks! -- Nikhil ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 > > where should I look upon and like possible sources of errors, it > > will be great help. > > I'm quite sure this is not a problem of `ftview'. Similarly, I'm > quite sure it is not a problem of FreeType's caching code either. > Ok. > What about trying `ftstring' instead? IIRC, it doesn't use the > caching code; debugging it should thus be simpler. > Yes! I'll do that. Thanks. Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 > where should I look upon and like possible sources of errors, it > will be great help. I'm quite sure this is not a problem of `ftview'. Similarly, I'm quite sure it is not a problem of FreeType's caching code either. What about trying `ftstring' instead? IIRC, it doesn't use the caching code; debugging it should thus be simpler. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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. > 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 where should I look upon and like possible sources of errors, it will be great help. > > * PK Driver: The `pk' driver is almost similar to the `gf' driver. > > I have added all the code for the pk driver in the branch > > `parthw-pk-vf'. The driver is running properly and allocating > > bitmap values like the gf driver! > > Good, too :-) Still waiting for an image from `ftview'... > Will get it running soon! :-) > Please let me know if there are any instructions for me :-) > > I suggest that you get rid of `UINT' and friends, replacing it with > `FT_UInt' and similar FreeType entities. This should (a) make the > source code appearance more uniform, and (b) it should make debugging > easier since you have to remember less typedefs. > Ok. Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Theme designs for the FreeType Website
> 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 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 size a bit. > The API reference is at > https://www.dxdy.ooo/freetype-web-jekyll/docs/reference/ft2-toc/ This looks great, thanks! Some suggestions. * What do you think about allowing line breaks after (or alternatively before) `_' in verbatim text. Example: `CFF_CONFIG_OPTION_OLD_ ENGINE'. * It would be great if you could harmonize the appearance of the API reference with the remaining website. As a starter, it could use the same serif font. I can also imagine to slightly adapt the website to the appearance of the API reference in case this is simpler or more efficient. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FontVal changes and the next set of test results of libre fonts
> The test results of all of fedora shipped fonts - about 3600 of > those - around mid-May, using the system's enhanced freetype > library, at 10pt, is here > http://htl10.users.sourceforge.net/tmp/fc28-ras-results.tgz Thanks! Anything I (as the FreeType maintainer) should look at? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Updates to Docwriter: Logging, testing, linting
> I've been working on improving docwriter's maintainability. These > are the changes made in the past few days: [...] Thanks for working on that. It looks very clean! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 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... > * PK Driver: The `pk' driver is almost similar to the `gf' driver. > I have added all the code for the pk driver in the branch > `parthw-pk-vf'. The driver is running properly and allocating > bitmap values like the gf driver! Good, too :-) Still waiting for an image from `ftview'... > Please let me know if there are any instructions for me :-) I suggest that you get rid of `UINT' and friends, replacing it with `FT_UInt' and similar FreeType entities. This should (a) make the source code appearance more uniform, and (b) it should make debugging easier since you have to remember less typedefs. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
