we can at least isolate the problem this week and then you
can decide whether to delay releasing until we can propose a good fix.
Regards,
Ken Sharp
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https
At 14:31 25/01/2018 +0300, Ann Brednikhina wrote:
Thanks for your quick reply!
But the situation with git clone is absolutely the same. I have cloned
http://git.sv.nongnu.org/r/freetype/freetype2.git
c:\GIT\freetype2>grep -RnP --color=always FT_IncrementalRec .
At 11:51 25/01/2018 +0100, Werner LEMBERG wrote:
> Please send me a link to the full sources or some instructions how to
> add into our project.
Incremental glyph loading is contributed code; I'm not familiar with
it. I hope that Chris or some other person from Artifex (the
ghostscript
At 09:09 05/08/2016 +0100, Graham Asher wrote:
I see your point, but I think that adding obfuscation (the extra
complexity introduced by using C) to the code to support a tiny and
vanishing minority of systems without C++ is not worth the bother; such
systems would very probably not be able
At 20:31 23/10/2013 +0200, Werner LEMBERG wrote:
Just wish to point out that a copy of the whole of freetype is
bundled with ghostscript, and ghostscript has been routinely built
for win64 for quite a few years. For as long as it was, the
preferred compiler for building ghostscript for
At 10:26 30/08/2012 -0400, Alexei Podtelezhnikov wrote:
Can we ask FreeType users what do they want to have and have simplified in
API?
What do they not need too?
By users I mostly mean:
- Cairo and Pango (Behdad ?)
- Qt
- fontconfig
- ghostscript (Ken Sharp ?)
Should be Chris Liddell
At 15:18 24/08/2012 +0200, Werner LEMBERG wrote:
Thank you for your prompt response. I am surprised, because when
embedded in a PDF file, the font is displayed incorrectly by
GhostScript 9.02 which uses FreeType 2.4.3.
Indeed, using ftview from 2.4.2 and 2.4.4, the font fails splendidly.
At 11:20 29/07/2010 +0200, Werner LEMBERG wrote:
can you answer this mail?
No problem :-)
I. IMPORTANT CHANGES
- Since May 2010, all patents regarding the TrueType bytecode
interpreter have expired worldwide. Consequently, we now define
At 10:04 08/06/2010 +0200, Werner LEMBERG wrote:
I am sceptical about the need to calculate both da and db. Perhaps
db only will suffice. I hope that David or Werner can comment.
This is something Ken can probably check: He has a large database for
Ghostscript to compare rendering results,
At 13:44 21/03/2010 +0100, Werner LEMBERG wrote:
Needed some minor tweaking for Windows (inttypes.h doesn't exist, so
conditionally typedef FT_Int64 as __int64)
Patch, please.
Uploaded alongside the issue report, it really is quite trivial.
Should I open an issue in Savannah and attach
At 23:32 20/03/2010 +0100, Werner LEMBERG wrote:
However, I did notice while reading ftraster.c that it can be built
stand-alone without the rest of FreeType (I hope that's not just a
legacy comment ;-)
I check regularly whether it compiles, and a few months ago someone
even sent fixes for
At 08:08 20/03/2010 +0100, Werner LEMBERG wrote:
Can you provide a font which I can use to do some debugging? Which
parameters shall I use for, say, ftview?
Hi Werner, this is a PostScript font, not a TrueType, and as usual it
depends on using Ghostscript as the FreeType client, so I can't
Hi James, all,
At 10:49 18/03/2010 -0400, James Cloos wrote:
It looks like ftraster.c:Vertical_Sweep_Drop() is responsible for that.
Actually this routine never gets called in either case. It seems the
vertical pass processing decides there is nothing to do. That is, in
Render_Single_Pass
Hi James,
At 10:49 18/03/2010 -0400, James Cloos wrote:
KS This is the point for discussion, it seems to me that the location
KS of the feature within the pixel should not have any effect on
KS whether the pixel is marked or not, that should only depend (In my
KS opinion of course) on the size
Hi all,
This may or may not be regarded as a bug, so I thought I'd put it up for
discussion before potentially raising it as an issue.
Background
===
I've been interfacing Freetype with Ghostscript for some time. The project
is going pretty well on the whole, but as you can imagine
At 19:21 13/01/2010 +, rsr wrote:
Hi,
Can any one please explain me what is
nominal width, 26.6 fractional points
Its a way of representing a non-integer number in a 32-bit word. The first
26 bits are used to represent the integer portion of the number so the
integer can vary from 0 to
At 17:03 22/06/2009 +0200, Werner LEMBERG wrote:
The `FT_Incremental_MetricsRec' expects integer values. My suggestion
is to introduce a new function `get_fractional_glyph_metrics'; if this
function is defined, use it, otherwise use `get_glyph_metrics'.
Objections?
Looks fine to me, should
17 matches
Mail list logo
