Hi,
I guess this is primarily aimed at Werner, but posted here for any
interested parties to comment.
I'd like to add a callback to the memory management specifically for
(re)allocating bitmap/raster memory.
My intention would be to have the API call take a bitmap struct as it's
parameter, and
On 26/07/2010 05:32, Werner LEMBERG wrote:
My intention would be to have the API call take a bitmap struct as
it's parameter, [...]
I assume that you want to implement a new API function, right? For
backwards compatibility it's not possible to alter the existing ones.
Yes. Actually, two
Hi Folks,
Hopefully, I'm not going nuts, but the updates to afdummy.c (on
2011-01-23) added AF_Err_Ok for the return values, but didn't define it
anywhere.
I assume there's a header file missing from the push?
Thanks!
Chris
___
Freetype-devel
Hi Folks,
I'm looking at getting Type 1 font data *out* of Freetype to use in
Ghostscript - in other words, using FT to parse a Postscript T1 font stream,
and then retrieve the data to build a Postscript font dictionary for use by
Ghostscript.
At moment, I don't see public API call(s) to
On 26 October 2011 18:41, Werner LEMBERG w...@gnu.org wrote:
So, is this something amenable to change?
I'm not sure whether this really works. While you get most
informations from a `standard' Type 1 font with FreeType's parsing
algorithm, there are examples like Adobe's `optima' family
On 27/10/11 10:48, Werner LEMBERG wrote:
[...] For reasons I won't bore you with, we do need to be able to
create a (fairly) valid Postscript type 1 font dictionary which can
be seen by the Postscript interpreter. We're only talking about
Type 1 streams from PDF files, in Postscript jobs we
This looks very much like a winding-rule issue. Despite Adobe's font
documentation claiming that glyphs should be rendered with non-zero
winding, the Adobe *font* scalers/renderers actually use even-odd.
This can be seen in CPSI (if anyone has access to it), by drawing a
series of glyphs
On 08/08/12 23:07, Werner LEMBERG wrote:
If this looks like becoming more important, and no one else is up
for it, I can try to focus more time on the task.
Yes, it would be nice if you could work on this. However, a malformed
font is a malformed font. Actually, Ivan should send a bug
On 06/09/12 07:05, Werner LEMBERG wrote:
Another example that I recently stumbled across (and haven't yet
investigated fully) is the rendering of notdef glyphs. For Truetype,
Freetype is (correctly) using the TTF notdef glyph (the empty
rectangle), but for Postscript/PDF/PCL/PXL, the notdef is a
) or the
bounding box information to determine line breaks.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
From 05a0da6fa15a4d424fcc4555bce8cc88b8b0ecd4 Mon Sep 17 00:00:00 2001
From: Chris
On 19/09/17 16:06, Alexei Podtelezhnikov wrote:
> Hi guys,
>
> I will be doing some FreeType development on Windows 10 in this
> release cycle. It was surprisingly easy to set up the environment. I
> only needed two things:
> 1) Git for Windows, https://git-for-windows.github.io/, which comes
>
On 21/09/17 14:24, Alexei Podtelezhnikov wrote:
> On Thu, Sep 21, 2017 at 3:32 AM, Chris Liddell
> <chris.lidd...@artifex.com> wrote:
>>
>>
>> My point was whether "dropping vc2005" meant just the VS2005
>> project/solution files, or whether
On 20/09/17 17:00, Alexei Podtelezhnikov wrote:
> On Wed, Sep 20, 2017 at 10:01 AM, Chris Liddell
> <chris.lidd...@artifex.com> wrote:
>>> - drop vc2005 and earlier support altogether as those compilers have
>>> reached their EOL.
>>> - drop wince as
I'm messing with Freetype's MultipleMaster Type 1 support, and I notice
there's no way to directly set the weight vector. That's a bit of a pain
because working backwards from the weight vector values really isn't
viable, and Adobe does let you set the weight vector directly.
I'm guessing setting
On 13/02/18 07:17, Werner LEMBERG wrote:
>>> Maybe we can announce in the forthcoming release that we are
>>> switching to C99 later on.
>>
>
>> I have no objection to have some conditional parts for C99-specific
>> feature, but I feel negative with the total migration to C99. "For
>> LLP64
On 02/04/18 16:04, Werner LEMBERG wrote:
>
>> We're currently experiencing a problem with FreeType 2.9 in
>> conjunction with Ghostscript. Some TrueType glyphs are rendering as
>> if the hinting is broken, or points are being moved/dropped.
>
> Interesting.
>
>> If your projected timescale is
On 03/04/18 15:12, Alexei Podtelezhnikov wrote:
We're currently experiencing a problem with FreeType 2.9 in
conjunction with Ghostscript. Some TrueType glyphs are rendering as
if the hinting is broken, or points are being moved/dropped.
>>
>> Well, the good news is that the
On 27/11/2018 21:25, Werner LEMBERG wrote:
>
>> Revised (I fixed some/all(?) of the 2/4 space indent confusions):
>>
>> https://tinyurl.com/ydyx2sjs
>
> Massaged and applied to git, thanks!
Thanks Werner, much appreciated.
Chris
___
Freetype-devel
On 21/12/2017 07:47, Werner LEMBERG wrote:
>
>> I'm guessing setting the weight vector directly isn't included
>> because it wasn't originally part of Adobe's MM usage.
>
> Maybe. Another reason was probably the goal to have a uniform
> interface for both MM and GX fonts.
>
>> I'd like to add
On 23/11/2018 16:44, Werner LEMBERG wrote:
>
I'd like to add the ability to set/get the weight vector directly
(FT_Set/Get_MM_Weight_Vector), [...]
>>
>> I've taken a first pass at this:
>>
>> https://tinyurl.com/yatcd4xn
>>
>> I'm sure I've messed up some coding standard, or API detail
On 26/11/2018 05:33, Werner LEMBERG wrote:
>
I'd like to add the ability to set/get the weight vector directly
(FT_Set/Get_MM_Weight_Vector), [...]
>>
>> I've taken a first pass at this:
>>
>> https://tinyurl.com/yatcd4xn
>>
>> I'm sure I've messed up some coding standard, or API detail
On 07/01/2019 20:07, Alexei Podtelezhnikov wrote:
>>> I am testing with ftview and ftstring: statically linked - no
>>> problem. dynamically linked - yes problem.
>
> "make devel" defines T1_CONFIG_OPTION_OLD_ENGINE, which calls
> t1_decoder_parse_charstrings and it works.
> otherwise,
Sorry folks... hit the send button by mistake
On 13/02/2020 12:20, Chris Liddell wrote:
> Hi Werner,
>
> On 04/02/2020 11:46, Werner LEMBERG wrote:
>>
>> Hello Chris,
>>
>>
>>> We use Freetype with Ghostscript. We have also been using coveri
Hi Werner,
On 04/02/2020 11:46, Werner LEMBERG wrote:
>
> Hello Chris,
>
>
>> We use Freetype with Ghostscript. We have also been using coverity
>> static analysis for quite some time, [...]
>>
>> Would you (mainly Werner, but others too) consider there to be value
>> in us doing the same for
Hi all,
We use Freetype with Ghostscript. We have also been using coverity
static analysis for quite some time, but during the last 4/5 months,
we've had a concerted effort to get our sources free of coverity issues,
and that finally happened in the last week or two.
We're now discussing whether
So, we've had a report that building Ghostscript against Freetype 2.10.3
fails because FT_CALLBACK_DEF() has been moved to internal use only.
Ghostcript supplies callbacks for memory management (i.e. FT_MemoryRec)
and we used FT_CALLBACK_DEF() for those, which seemed logical when
defining
On 12/10/2020 17:47, Alexei Podtelezhnikov wrote:
>
> > So, we've had a report that building Ghostscript against Freetype
> > 2.10.3 fails because FT_CALLBACK_DEF() has been moved to internal
> > use only.
> >
> > Ghostcript supplies callbacks for memory management
> >
On 12/10/2020 18:00, Chris Liddell wrote:
> On 12/10/2020 17:47, Alexei Podtelezhnikov wrote:
>>
>> > So, we've had a report that building Ghostscript against Freetype
>> > 2.10.3 fails because FT_CALLBACK_DEF() has been moved to internal
>> > us
Hello Werner and all,
We've encountered a problem with our use of Freetype in mupdf.
We have a PDF with an embedded OTTO/CFF font that is used as a CIDFont
in the PDF.
Now, the way CIDFonts work in PDF is that the character code is mapped
through the PDF CMap, to get a "glyph index".
In the
On 13/12/2021 17:44, Alexei Podtelezhnikov wrote:
> On Mon, Dec 13, 2021 at 12:17 PM Chris Liddell
> wrote:
>> In the case of a font with CFF outlines, the "glyph index" should still
> be mapped through the CFF Charset.
>
> The native CFF charset as well
On 21/03/2023 22:00, Claudiu Milea wrote:
Hi,
We encountered a few (potentially not fully compliant with the
specification) CFF fonts (i.e. CIDFontType0) that have enough
information to be rendered, but FreeType throws an exception due to not
having both the `head` and the `cmap` tables.
31 matches
Mail list logo
