Re: [ft-devel] Need clarification on font cutoff
I couldn't recollect the reason behind using version 2.8.1. Sure, I will give a try with a new version and update. Thanks. Regards, Madan On Fri, Jul 13, 2018 at 1:41 AM, Werner LEMBERG wrote: > > > Also, we are seeing some light lines, or dots are coming in between > > characters for some x scale value (say 0.75) (this is also > > attached). Do you have any inputs on how to address this extra > > dots/lines? > > Is there a specific reason why you don't try the latest FreeType > version? Chances are high that it was fixed in 2.9.1: > > - Emboldening of bitmaps didn't work correctly sometimes, showing > various artifacts (bug introduced in version 2.8.1). > > In the future, please make my life easier and use the latest release – > or even better, please try the current git version. > > > 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
> > > 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. > > [...] > > Since I have no idea what you are talking about, I won't comment this > further :-) It's a different way of designing classes with some benefits as explained in the article. > > ___ 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
> * Any reason for the "# eof“ comments at the bottom? I want that; I consider it good practice to mark the intended end of file. > 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. > [...] Since I have no idea what you are talking about, I won't comment this further :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Need clarification on font cutoff
> Also, we are seeing some light lines, or dots are coming in between > characters for some x scale value (say 0.75) (this is also > attached). Do you have any inputs on how to address this extra > dots/lines? Is there a specific reason why you don't try the latest FreeType version? Chances are high that it was fixed in 2.9.1: - Emboldening of bitmaps didn't work correctly sometimes, showing various artifacts (bug introduced in version 2.8.1). In the future, please make my life easier and use the latest release – or even better, please try the current git version. Werner ___ 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 Werner for the details. Font file is ttf based. And cut-off randomly
happened only for few letters. I tried your suggestion of taking ascend
parameter from global FT_Face structure, after which issue is not coming.
Also, we are seeing some light lines, or dots are coming in between
characters for some x scale value (say 0.75) (this is also attached). Do
you have any inputs on how to address this extra dots/lines?.Attached is
screenshot. Freetype version is 2.8.1. Please guide how this problem need
to be addressed.
Thanks.
Regards,
Madan
On Thu, Jul 12, 2018 at 10:20 AM, Werner LEMBERG wrote:
>
> > We are using freetype-2.8.1. When we try to print the text
> > characters, sometimes little top portion of text characters got
> > stripped off. Pixel size passed to FT library is 30. No issue is
> > seen with freetype-2.5.2.
>
> Please give an example. Which font, which character, which hinting
> mode?
>
> > It is seen, ascent value returned from font metrics is not returned
> > properly from the ttdriver.c in recent versions of freetype.
>
> Have you seen the following entry in the `CHANGES' file for
> version 2.8?
>
> Global size metrics values in the `FT_Size_Metrics' structure can be
> different for TrueType fonts. Reason is that in older FreeType
> versions the metrics were rounded differently to integer pixels
> compared to all other font formats, yielding an inconsistent
> behaviour if you used non-native hinting. Starting with this
> version, global size metrics for TrueType fonts are handled the same
> as other font formats: `ascender' gets rounded up, `descender' gets
> rounded down, `height' gets normally rounded, and `max_advance' gets
> normally rounded, too.
>
> If you need more precise values of (global) ascender, descender,
> height, or `max_advance', please take the corresponding values from
> the `FT_Face' structure and scale them manually.
>
> In version 2.9 I updated the documentation for `FT_Size_Metrics' as
> follows.
>
>TrueType fonts with native bytecode hinting
>---
>
>All applications that handle TrueType fonts with native hinting
>must be aware that TTFs expect different rounding of vertical font
>dimensions. The application has to cater for this, especially if
>it wants to rely on a TTF's vertical data (for example, to properly
>align box characters vertically).
>
>Only the application knows _in_ _advance_ that it is going to use
>native hinting for TTFs! FreeType, on the other hand, selects the
>hinting mode not at the time of creating an @FT_Size object but
>much later, namely while calling @FT_Load_Glyph.
>
>Here is some pseudo code that illustrates a possible solution.
>
> font_format = FT_Get_Font_Format( face );
>
> if ( !strcmp( font_format, "TrueType" ) &&
> do_native_bytecode_hinting )
> {
>ascender = ROUND( FT_MulFix( face->ascender,
> size_metrics->y_scale ) );
>descender = ROUND( FT_MulFix( face->descender,
> size_metrics->y_scale ) );
> }
> else
> {
>ascender = size_metrics->ascender;
>descender = size_metrics->descender;
> }
>
> height = size_metrics->height;
> max_advance = size_metrics->max_advance;
>
>
>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
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 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? * 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. * Any reason for the "# eof“ comments at the bottom? * I suggest you fix the `import *` statements and instead be explicit. * 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. 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: ``` class Formatter(object): def __init__(self, processor, identifiers, chapters, sections, block_index): self.processor = processor self.identifiers = identifiers self.chapters = chapters self.sections = sections self.block_index = block_index @classmethod def with_processor(processor): # construct all that's needed return cls(processor, identifiers, chapters, sections, block_index) # … # Instantiation: formatter = Formatter.with_processor(…) ``` ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] COLR/CPAL
Hi, Looks to me like FT_HAS_COLOR still returns false for COLR/CPAL fonts. Any idea? -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[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 now be run with the `--quiet` or `--verbose` options (thanks to logging levels), and this is very helpful for debugging. * I have added Travis CI testing with various unit tests and an integration test. With this, every commit is tested with multiple versions (both 2 and 3) of Python. Test results are always available at https://github.com/nikramakrishnan/freetype-docwriter (in the README part below) and https://travis-ci.com/nikramakrishnan/freetype-docwriter. * I have also added Landscape's code 'health' monitor, which uses multiple linting tools to rate the code's quality. Please let me know if there are any comments or suggestions! -- Nikhil ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FontVal changes and the next set of test results of libre fonts
Hi all, Since mid-May actually, for about two months now, I have been running my fedora linux box with the system freetype fully patched /enabled with the FontVal changes without noticeable problems. To recap, when Microsoft opened the Font Validator code base, they left out a few pieces, one of which was the part which does truetype hinting instruction analysis (a.k.a. "rasterization tests"). A replacement based on FreeType was gradually developed over the last 3 years, and was "feature complete" (as in, implementing all of the previous, more or less) last summer. There were some discussion about up-streaming those changes; and before that can happen, if at all, they must not interfere with normal freetype usage as the system font renderer. So anyway, 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 and at the beginning of June I also collected all the test results, again at 10pt, for all Ubuntu WSL (supposedly 16.04) shipped fonts, again about 3500 of them - is here http://htl10.users.sourceforge.net/tmp/ubuntu-wsl-reports.tgz Font owners etc can have a look. There were some interface adjustments to both the C# binding and the python binding to the enhanced backend for adapting to system-freetype usage, at https://github.com/HinTak/freetype-py , font-diag branch. https://github.com/HinTak/SharpFont , v4??+fixes branch. The next important change to Font Val has to be re-enabling building with MS visual studio. Apparently at least two people have had a go (without trying to tell me to co-ordinate the effort)... according to the network of forks... https://github.com/Microsoft/Font-Validator/network https://github.com/HinTak/Font-Validator/network ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
