> afloader.c also contains this quip:
>
> /*
> * TODO: This code currently doesn't support fractional advance widths,
> * i.e., placing hinted glyphs at anything other than integer
> * x-positions. This is only relevant for the warper code, which
> * scales and shifts glyphs to optimize blac
> One more thing, I just noticed that, using ftview, switching hinting
> on (no matter if native and autohinting) and off in NotoKufiArabic-
> Regular.ttf, NotoMono-Regular.ttf and some other Noto fonts makes
> some glyphs jump, changing the layout. I don't think this should be
> happening?
It's
> Werner noted that CFF's current rounding of the advance width is a
> bug,
If used in `light' mode. Otherwise, it's OK, I think.
> however, I didn't find the culprit on a cursory look...
Will check later.
___
Freetype-devel mailing list
Freetype-de
> Specifically, would you agree with this plan?
>
> - Autohinter warping option will migrate from LIGHT to NORMAL
There are some issues.
. NORMAL currently means full auto-hinting, i.e., hinting along both
the horizontal and vertical axes. I believe we can't change that.
. Since NORMAL alre
>> It's not clear to me what you want. Please elaborate.
>
> When you use subpixels for glyphs, you might as well use subpixels
> for the advance width ;) I think using the TrueType interpreter v38
> and v40 should turn on fractional advance widths for TrueType
> fonts. Maybe you can turn it on
>> . NORMAL currently means full auto-hinting, i.e., hinting along
>> both the horizontal and vertical axes. I believe we can't change
>> that.
>
> I see warping is a kind of hinting where shifting/scaling is tweaked
> for all segments at once rather than for each segment individually.
> Ther
> fractional advance width: this seems to need more thought.
Indeed :-) Thank for you participating in this discussion.
> If that's to be used for the intended purpose, don't we need
> rendering modes with different fractional offsets? i.e. let's say
> you want to lay out 'abc'. 'a' has a fra
>> However, it would fail miserably if lsb_delta and rsb_delta are
>> used to adjust integer advance widths by ±1 pixel, as documented in
>> the FreeType reference. *This* is what we can't neglect IMHO.
>
> With warping out of the way, the light mode becomes a clean case.
> The left phantom poin
>> Note, however, that ftview doesn't use fractional advance widths –
>> it simply doesn't make much sense for this application.
>
> What bothers me that since both light autohinting and no hinting
> should return identical fractional advance widths, no layout change
> should happen...
I think i
>>> Fractional advance widths imply that you do have to send a glyph
>>> positioned at a sub-pixel position to the TT engine. It's
>>> something to investigate how to do that...
>
> Doh, wait, you need to render fractionally shifted bitmaps. Well,
> you can always shift the hinted outline right
>> Somehow the hinting engine must know the fractional offset,
>> otherwise it can't do sub-pixel hinting – either an explicit
>> argument, or the position of the left phantom point, or...
>
> Huh??? Filtering blurs all boundaries. Repeat 10 times. It blurs
> pixel boundaries. It also blurs s
>> Repeat 10 times: There also exists grayscale ClearType! Not
>> everything is LCD :-)
>
> Hinting a glyph after arbitrary shift will result in visibly
> different widths.
So what? I'm talking about ClearType hinting that *does* change
advance widths if necessary, but more subtle than `normal
>> I'm not talking about `light' mode! `lsb_delta' and `rsb_delta'
>> were mainly introduced for `normal' (i.e., `strong') auto-hinting.
>
> B Do not confuse me please. Normal hinting and warping for
> that matter would not benefit from subpixel positioning. Therefore,
> they neither n
>> Maybe we are miscommunicating. Subpixel positioning does *not*
>> imply the same advance widths as with unhinted rendering.
>
> Maybe. I am talking about width as in bounding box that may and
> will change if you shift and hint.
I don't understand this your paragraph. Please reformulate.
> In subpixel positioning you have to shift glyph to take into account
> previous fractional advance. If you follow that by hinting, the
> result is not deterministic. The bounding box may differ by 1
> pixel. Warping is more stable basically because its shift will undo
> some of the original s
Ewald, Arvinder, Kushal,
welcome to FreeType! Yesterday the accepted GSoC projects were
officially announced, and I'm looking forward to having three
motivated new members in our community.
Originally, we had four excellent proposals, but one student submitted
a proposal for another organizati
> I suggested to Google to split up this very large project into two
> subprojects that don't overlap [...]
Just to avoid misunderstandings: This split up doesn't mean that
Arvinder and Kushal will do only half of the work that sums up to the
whole thing. It's rather that we now have a chance to
> Mixed Content: The page at 'https://www.freetype.org/index.html' was
> loaded over HTTPS, but requested an insecure image '
> http://api.flattr.com/button/flattr-badge-large.png' (index.html :
> 720). This content should also be served over HTTPS.
>
> Need to change the 'http://...' to 'https:
> This was already some time ago, so I hope it's ok if I send it to
> the list now to get it out of the pipeline.
Thanks a lot! I'm struggling with some nasty and time consuming
issues which still delay the release...
> The commits were made starting at 1dd90ae. I can rebase if needed.
Please
> I'd just like to point out a couple of resources for the rendering
> testing framework. [...]
Thanks!
Ewald, any information you need or want? I just want to point out
that the `fonttools' project might also give you further pointers for
the Type1->CFF transition.
https://github.com/font
>> In general, I like a conservative approach so that C++ code can be
>> compiled even on older boxes. Admittedly, I'm not a big fan of C++
>> (and not a big C++ coder either), but given that FreeType itself is
>> written in quite conservative code, `qtinspect' should probably use
>> a similar pat
> I just want to clarify source control / merging workflow around
> here. Is it only using difference files via mail? I have made a
> fork onto Github, but I'm not sure if you'd like to use that for any
> vetting/review purposes.
I think it's better that I give you write access to the FreeType
> Actually Werner's preference to have rebase regularly might be a bit
> disrupting to students who are trying out git and doing wild things at
> the same time... there are going to be a lot of collisions, etc, if
> one is also trying stuff out.
Well, as mentioned in another mail, I don't care wh
> It seems that your solution to
> https://savannah.nongnu.org/bugs/index.php?50560
> is simply wrong - it turns a warning into a complete failure :-).
Thanks for testing! I've applied your patch.
> I am not sure if __int64 is specific to mingw-gcc or would it breaks
> compiling with visual st
> https://www.freetype.org/freetype2/docs/design/design-4.html
>
> In this page, under section 4. Libraries , the third bullet point
> has the word "owner" instead of "owned". :)
Fixed, thanks.
Werner
___
Freetype-devel mailing list
Freetype-de
FreeType 2.8 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/projects/freetype/files/
The latter site also holds older versions of the FreeType library.
See below for the relevant snippet from the CHANGES file.
Enjoy!
Folks,
I've completely revised and updated the `FreeType design' guide.
Alas, it's still incomplete – volunteers to help fill the gaps are
highly welcomed...
Enjoy!
https://www.freetype.org/freetype2/docs/design/index.html
Werner
___
Freetype
>> I can only repeat: Hinting and subpixel positioning *can* work
>> together! There is absolutely no reason why this shouldn't be
>> possible.
>
> The brilliance of lsb_delta and rsb_delta method is that it
> recognizes that two extreme edges of the glyph are hinted mostly
> independently. For
> I think the size handle is invalid (with both x scale/y scale zero):
>
> ===
> FT_Request_Size (font driver's `request_size'):
> x scale: 0 (0.00)
> y scale: 0 (0.00)
> ascender: 160.00
> descender: -50.00
> height: 210.00
> max advance: 160.00
> x ppem: 16
>> Well, lsb_delta and rsb_delta are derived from the horizontal
>> phantom points. Given that the idea of `phantom points' is
>> originally a TrueType concept, I don't see why this shouldn't work
>> with TrueType hinting.
>
> Currently there is a need to adjust pen position when hinting places
>
I wonder how to add `gasp' table support for TTFs. A new load flag?
Or maybe a TrueType driver and/or face property? The basic idea is
that you call `FT_Load_Glyph', and you get the optimal rendering for
TTFs depending on the `gasp' table settings – there are good reasons
to use it...
Suggestio
> I'm trying to render a Chinese text on Horizontal and I'm using a
> ttf file which contains both metrics inside (Horizontal and
> Vertical). The glyphs obtained seems to be based on Vertical
> metrics.
I don't understand what you mean. Can you repeat the issue with one
of the FreeType demo pro
>>> Currently there is a need to adjust pen position when hinting
>>> places two adjacent glyph edges too near or too far. This concept
>>> does not go away with subpixel pen positioning.
>>
>> Why do you think so? Where is the difference to the integer case?
>
> Let's trace all the steps backwa
> “This license applies to all files found in such packages, and
>which do not fall under their own explicit license.”
>
> The question my lawyer has is "What files in the FreeType Project
> package have their own explicit license as those will need to be
> evaluated too?"
All such files a
>> there are good reasons to use it...
>
> Which are? :D
I assume this is a rhetorical question, but I guess it isn't obvious
to everyone, so I'm answering it :-)
In most cases the designer of a font know best how to display the font
in an optimal way. In particular, manual hinting of a font o
> No more states in the library please (ie. driver property).
This driver property would be also part of the face – some properties
were already added to FT_Face so that they can be used by function
`FT_Face_Properties'. The advantage of a driver property is that you
have three levels of control
> I admittedly misunderstood grayscale normal hinting.
:-)
> Let's recoup and see if you agree
I assume that you are talking about TrueType fonts.
> In MONOCHROME mode subpixel positioning is impossible because stems
> are nailed to grid. Any shift in the start position will either be
> ignor
> Are there any plans to add controls/parameters to Freetype for the
> rendering of glyph brightness, contrast, weight, etc?
No.
> The "Infinality" patch set does/did provide some of these types of
> parameters:
>
> INFINALITY_FT_GAMMA_CORRECTION
> INFINALITY_FT_BRIGHTNESS
> INFINALITY_FT_CONTR
> I've got a downstream report that a PCF font is not showed in
> gnome-font-viewer (see
> https://bugzilla.redhat.com/show_bug.cgi?id=1451795).
>
> After some debugging I've found that since the gnome-font-viewer
> uses FT_Get_First_Char() and FT_Get_Next_Char() it needs a charmap
> defined in i
> Thanks for the kind note Graham! I love these bits of history :))
Yeah, and you will always be welcome!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
>> It is a question of taste how the filter should behave, one could
>> argue. There always was a fair of difference between Windows and OS
>> X in this regard, for instance.
>
> Yeah, that's a bit of a problem - how can we precisely define what
> is "correct", and if someone is doing something t
> Hm, how about writing this in Markdown format as far as possible and
> then converting it to HTML for site upload? That would make
> authoring and maintenance easier.
Maybe, but *converting* the existing documentation to Markdown format
costs a lot of time and energy. For me, it's much easier
> See v2 of the patchset attached. I
> * rebased on master (only change was light vs slight if I catched that
>correctly)
> * removed all C++11-related stuff (auto, override, static_assert,
>std::intptr_t)
I've now applied the last patch of your set manually to the git
repository, adjus
> I found glyphs in this font cannot be loaded without
> FT_LOAD_NO_HINTING.
*Please* don't send such big fonts to the list! Instead, you should
provide a link.
Actually, I'm surprised that it was distributed by the list at all –
theoretically, I should have received a message that the e-mail i
Hello Ewald!
> - The cff code moved to psaux still uses functions defined in
>cff/cffload.h. However, some cff code not moved is also sharing
>some of these.
As you've correctly observed, this must not happen: Header files in
`src/cff/' are local to this subdirectory. As a solution,
> > Although I'm unsure of the feasibility of it, my initial thought
> > was to sum the pixel intensity differences between the baseline
> > and test glyphs . Supposedly, these values could be stored for
> > every glyph (although maybe not for 12 million) in an index, and
> > we could consider the
>> There you go. This change breaks Skia:
>> http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=ab2599ea3f09ba8da4f50b877021d23241d22609
>>
>> This is what Skia shoudl not do by itself
>> https://skia.googlesource.com/skia/+/master/src/ports/SkFontHost_FreeType.cpp#1180
>>
>> This
>> Distributions regularly apply patches to packages to suit their own
>> needs. I don't see any problem here. Honestly, I think that the
>> number of single users who compile Firefox or Chrome from scratch
>> is quite limited, thus the impact of this change is rather low –
>> it's not released
>> You think that distributions will do an update to FreeType 2.8.1
>> (to be released in a few months, I guesstimate) *before* they do an
>> update to Chrome or FreeType? I consider this very unlikely.
>
> Then what about all these electron apps like vscode? They use an
> old Chromium version
>> So all I'm saying is that this patch will cause many problems and I
>> don't think the gains are worth the pains.
>
> I disagree, but thanks for the heads-up.
Alexei, could you please add a warning to the CHANGES file that
describes the problem with Chromium?
Werner
___
> Just for reference, what should be off-limits to client code?
Simply don't rely on internals. Use only the API and the public data
structures. If this isn't sufficient, file a bug report so that we
can discuss extensions. For some reasons, the Skia team didn't do
that – I guess the code in q
>> Simply don't rely on internals. Use only the API and the public
>> data structures. If this isn't sufficient, file a bug report so
>> that we can discuss extensions. For some reasons, the Skia team
>> didn't do that – I guess the code in question is a remnant from
>> early, experimental subp
>>> - It seems to be better to move the blend functions to the psaux
>>>service (except cff_done_blend and cff_blend_doBlend)
>>
>> What functions exactly do you mean?
>
> I'm referring to these:
> cff_blend_check_vector
> cff_blend_build_vector
> cff_blend_clear
These three look ok, ho
> a problematic font was encountered by reporter of this downstream bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1456585.
>
> The font there is Padauk-Bold.ttf (version 3.002 (it works with current
> upstream)). It has exc->cvtSize == 35 so the exc->loopcall_counter_max
> == 350 but exc->lo
>> All such files are explicitly mentioned at the end of the
>> `LICENSE.TXT' file.
>
> Is anyone able to confirm if there are any additional softwares
> incorporated into the Free Type Project other than the BDF and PCF
> drivers, gzip module and the MD5 checksum support? Thanks for any
> info yo
> I support controls to determine font weight.
Making the user control the font weight is against everything a font
designer wants! What you really mean is controlling the display
gamma, and this is, together with linear blending, a job to be done at
a higher level than FreeType.
> With freetyp
> I've written code
>
> 1. To generate bitmaps of a font face for desired size and rendering
>mode.
> 2. Store 32 bit and 128 bit hashes ( using MurMurHash3 ) for all the
>characters in a font face.
Great! Are you going to put your code into a public git repository?
> Now to generate fau
>> Also, I just pushed the changes I have tried making thus far to
>> savannah, in branch ewaldhew-refactor-cf2 (not cleaned). If
>> possible, please give it a quick look to see if I am going in the
>> right direction. (Most of the changes are cut-and-paste)
>
> Will do so tomorrow. Thanks for
>> . Recently, integer overflow run-time checking was activated
>> (again) for the fuzzer, causing a lot of minor code changes while
>> applying fixes. [...]
>
> I have been following those new OVERFLOW_* macros... they are a bit
> ugly and mostly purely for suppressing warnings?
Yes and yes.
>> Yes and yes. They are ugly, and I wonder whether I should drop the
>> `OVERFLOW_' part of its names to get `SUB_LONG', `ADD_INT32', etc.
>
> Please drop OVERFLOW.
OK.
> I see them as a red flag to rethink the code.
I disagree, at least partially, since...
> The add and sub overflows should
>> Ditto for bytecode. Checking every addition, subtraction or
>> multiplication for overflow is something I want to avoid,
>
> Of course, I am only suggesting rejecting input with unreasonably
> large coordinates or metric values.
This would be ideal, yes, but I don't see how you can do that.
> I am pretty sure that C refuses to define signed overflow and left
> shift of negative numbers because it does not want to accept "2's
> complement" as de facto standard.
Yes, this part of the C standard predates the dominance of two's
complement arithmetic.
> FreeType also pretends to be unco
>> . If you are going to clean up, please replace the `cf2' file name
>> prefix with something more generic.
>
> I think s/cf2/ps for the file names should be fine?
Yes, this looks good.
> I have rebased onto latest and did a force push (this branch is
> meant to be disposable). I hope that i
>> However, the majority of input data in most formats are deltas, and
>> here you would have to check after every addition, subtraction, or
>> multiplication whether you get something `unreasonable'.
>
> BTW are you aware of gcc's and clang's built-in functions that perform
> arithmetic with ove
> I also find all those changes a distraction that make the code look
> uglier for no gain. IMO warnings are just that: warnings.
Well, marking places where overflow is allowed to happen makes sense
IMHO. I'll soon drop the `OVERFLOW_' prefix, which should increase
readability again.
> When the
[Please *always* report such issues to the mailing list! I consider
it an important part of GSoC that the community stays informed,
possibly discussing the issue.]
> Just a heads up that I've pushed the commits for my changes so far
> into branch ewaldhew-cleaned on Savannah.
Thanks! Will ch
> 1. Get font from https://github.com/TypeNetwork/fb-Amstelvar
> 2. ftmulti 16 AmstelvarAlpha-VF.ttf
>
> """
> only handling first 6 GX axes (of 9)
> Segmentation fault
> """
Should be fixed in git. Please test, and thanks for the report!
Werner
__
> Thanks! I hope there isn't any problem with the rebase due to the
> removal of `OVERFLOW_' from the new macros.
I did a simple
s/OVERFLOW_//g
plus some reformatting...
> I get that each driver handles its own objects, so using the same
> object for either Type 1 or CFF seems wrong as we ha
Felipe,
> (I really miss a Freetype method to alter a single design-space
> coordinate, instead of having to pass the full array, by the way)
what API do you suggest? Given that normally an application wants to
control *all* axes, it is not obvious to me where the benefits are, so
please elabo
> > what API do you suggest? Given that normally an application wants
> > to control *all* axes, it is not obvious to me where the benefits
> > are, so please elaborate.
>
> In fontview or axis-praxis the ui is an array of sliders, and it is
> unusual for a user to have two or more pointers and
> I meant exactly what Dave said. While I agree that the data is
> there, a convenience method would help. Not as a strict necessity,
> but as a convenience :-)
OK, so I ask you again to provide a suggestion for an API.
Werner
___
Freetype-deve
[Resending – maybe you haven't received the previous message.]
Hello Arvinder!
Any news? Please write about once a week or so to the mailing list
about your progress. Even if there is no progress, or if you are
stuck, please tell us.
Werner
__
>> I guess the font is kind of buggy since newer versions of it i can
>> find in the internet render fine (i think this is an old version)
>>
>> But since it's still floating around, and fontforge seems to render
>> it fine maybe it can be fixed to render in freetype?
Nothing I can do here. The
[Hin-Tak, your citation style is extremely strange. Can you improve
that? This is, please mark *every* cited line with a citation
prefix, not only the first line.]
> > FreeType 2.8 doesn't work either. The last version that displayed
> > this font correctly with `FT_LOAD_DEFAULT' was 2.4.12,
Sorry for the late reply. Academic life is quite time consuming in
the end of the semester.
> I've pushed the code to generate bitmaps and hashes to branch
> ksvsk_test (dirty). Please look into it.
Thanks. Some general remarks regarding coding style: For me,
consistency is extremely importan
> I am using 32bit Bitmaps to give the bitmaps transparency and to
> overlap one over other.
>
> Google chrome / chromium are not able to display 32bit bitmaps
> whereas Mozilla Firefox is. Is there a way to enable chrome to
> display the images?
No idea, sorry. However, a solution shouldn't d
> When I open chrome/ Firefox the text rendered looks like this. [File
> attached, Zoom in]
This is the first time I see such artifacts. Have you looked up the
internet for users that experience similar problems?
Werner
___
Freetype-devel mailin
>> Please tell me again why you want to use the BMP format and not
>> something more compact – I forgot the reason...
>
> Well, this is the simplest / easiest way (not quite the compact way)
> to display the pixel data and also it is quite fast.
Is it? IIRC, we don't want to store BMP files on d
> As discussed, this patch implements synthetic Unicode charmap for
> sfnt if one is missing. I mostly copied it from cff and it requires
> the psnames module, which is not properly conditioned in the patch
> yet. I am not sure if it makes sense without psnames too.
> Comments?
This looks very
Hallo Jinattaporn!
> Regarding to the FreeType Project module, under BSD FreeType License
> that retained the copyright you are holding, [...]
The FreeType license is similar to BSD *plus* an advertising clause.
> 1. What is the properly sentence of copyright we need to describe in
> our work?
> P.S. Is it OK if I rebase my clean git branch onto master every so
> often and do forced updates?
Yes. This is your playground right now :-) I think this policy should
only be changed as soon as we are going to merge code into master – I
guess I'll then also commit stuff to your branch here a
> I've written code to generate PNG(s) instead of bitmaps for all
> types. (will give code tomorrow)
Great!
> I am using 32 bit (RGBA) PNG(s) for all types (mono, anti-aliased
> etc). I think alpha channel will be helpful for certain
> visualisations which take one image (glyph) to the backgro
> I'm using a command line argument now and have switched to using
> Kushal's code as well.
Excellent, especially the latter one :-)
>> Taking a glance on main.c, there are many hardwired values,
>> so I guess you would work more on it. My suggestion could
>> be in too early to give :-)
>
> Yes,
> val = val > 0 ? 0x7FFFL : -0x7L;
> ~ ^
> I stared a long time at this line until I saw there might be an "F"
> too much.
Doh. Fixed, thanks!
Werner
___
Freetype-devel mail
> A heads up that I've pushed a new branch ewaldhew-wip to savannah
> for ongoing work. I'll keep it based on the clean branch, and that
> on master.
OK, thanks.
> I had realised that the Type 1 and CFF builders contain practically
> the same data, [...] and I now believe there is no problem a
> What is the use of the "Difference" column?
Having a rough measure to weigh the differences sounds useful to me.
> Why do we need to prioritise any glyph which has an error big or
> small? Can't we just order them with glyph-index?
I would like to have the option to do both. Other options a
> I've pushed new updates to `wip'
Thanks. BTW, what shall happen with your other branches? Are they
now obsolete?
> I'm figuring if I could instead synthesize a dummy subfont record
> for Type 1, copying over relevant values, ...
This sounds sensible.
> ... but I am stumped for a good place
>> Thanks. BTW, what shall happen with your other branches? Are they
>> now obsolete?
>
> Sorry, that was unclear. I meant `ewaldhew-wip', which is for all
> ongoing work. There's also `ewaldhew-cleaned', which is for
> (hopefully) finalised stuff, with proper changelogs.
OK.
> I have no other
>>origin/ewaldhew-refactor-cf2
>
> Right, I had forgotten about this. It is indeed obsolete and I've
> already deleted it remotely.
Thanks. Just for everyone, since it is a rather seldom used command:
To remove a remote branch, type
git remote update --prune
Werner
___
> 1. Due to we already displayed your copyright on our product's
>display, Is there any problem if we will issue only the guideline
>sentence in the Instruction Manual such as " Please reference the
>copyright information as displayed on product" ?
I don't care. The main idea is that
> Does the Adobe engine result in different advance widths as with
> using the old engine?
It shouldn't – if you ever encounter such a situation, there is a
problem that needs to be analyzed.
Theoretically, the only difference is in hinting.
Werner
_
[Sending to freetype-devel also.]
>> PS: Arvinder, it looks strange to me that you have `-lfreetype' at
>> all in your building instructions. AFAICS, you access the
>> FreeType DLLs using dlopen – what FreeType functionality are
>> you using without dlopen?
>
> I was unsure about th
Hello Arvinder!
> This is something I wasn't sure about when dealing with different
> rendering modes. Should the different modes be organized and
> displayed separately? For example, if the glyphs were displayed
> side-by-side (to be compact vs. a list), the general idea
> (considering mono,
Hello Kushal!
> I am working on generating GIF(s) for that blink effect (with 2-3
> different visualizations to highlight differences).
I have no experience with animated GIFs: How do you control the
blinking? There must be an easy means to stop animation and clicking
between the states (from
> Let's say we have 5 images to be used for different visualisations
> A1, A2, A3, A4, A5. With this, I am able to generate animations for
> any combination of sub-images.
*Five* sub-images? What do you want to combine?
> I am also putting in code for changing the frequency of image
> transitio
>> *Five* sub-images? What do you want to combine?
>
> For example, we have
> 1. The base glyph
> 2. Rendered ( test ) glyph
> 3. Image with base glyph as grey background and errors as red pixels
> 4. Image with base glyph as it is and with errors as red pixels
> 5. Maybe some more visualizations
> Finally fixed and pushed Type 1 seac.
Great, thanks!
> One thing does bother me - the base characters of accented glyphs
> (using seac), i.e. the stuff appearing around the fifth row, seem to
> shift horizontally. This is especially obvious with the accented
> 'i's which appear off center in
> Perhaps a little too much to add a new Changelog entry for a
> one-character typo...
Indeed.
> Please feel free not to add the Changelog entry.
Yep. I've applied the rest of the patch, thanks!
Werner
___
Freetype-devel mailing list
Freetype-
>> Font X - Mono
>> [A][A'] [B][B'] [C][C']... (organized by id in this case)
>> Font X - Antialiased
>> [A][A'] [B][B'] [C][C']... (organized by id in this case)
>> Font X - LCD
>> [A][A'] [B][B'] [C][C']... (organized by id in this case)
>>
>> In comparison to a collated option which would look
> I've pushed the functions to stitch the PNG(s) and add effects and
> also written the code for the list view in the HTML page. (Using
> dynamic linking) (Rather than stitching PNG(s) together, I am
> directly producing sprite sheets. AFAICS, there is no need for the
> individual PNG(s).)
I've
401 - 500 of 4490 matches
Mail list logo
