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.
"C
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 as the
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 cas
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
>> &g
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
> > (i.e
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 callback
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 F
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
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, cf2_decode
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 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 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 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 t
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 corrupte
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 l
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 platf
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 25/09/17 08:30, Werner LEMBERG wrote:
>
> I've just committed Ewald's GSoC project to master. Please test!
>
Sorry, I've been a bit out of the loop on this
Does this mean that Type 1 hinting will now be applied to the scaled
outline?
Chris
On 21/09/17 14:24, Alexei Podtelezhnikov wrote:
> On Thu, Sep 21, 2017 at 3:32 AM, Chris Liddell
> wrote:
>>
>>
>> My point was whether "dropping vc2005" meant just the VS2005
>> project/solution files, or whether it was something more entailed, for
>>
On 20/09/17 17:00, Alexei Podtelezhnikov wrote:
> On Wed, Sep 20, 2017 at 10:01 AM, Chris Liddell
> wrote:
>>> - drop vc2005 and earlier support altogether as those compilers have
>>> reached their EOL.
>>> - drop wince as well since vc2012 and up supports
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
> wi
e advance width (this is new and now the default) 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 05a0da6fa15
On 07/09/12 03:34, Akira TAGOH wrote:
On Thu, Sep 6, 2012 at 11:32 PM, Chris Liddell
wrote:
I just think that Freetype should remain an engine which takes a font from
some source, and uses it to to create outline or bitmap glyphs. I would not
like to see Freetype getting sucked into loading
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
(Ken Sharp ?)
Should be Chris Liddell for Ghostscript now, though (obviously) I'm still
lurking and still interested :-)
Well, a few thoughts just off the top of my head (I suspect my
preferences won't be terribly popular).
As far a our use with Ghostscript is concerned, I would
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
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 lik
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 j
On 26 October 2011 18:41, Werner LEMBERG 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 where
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 retrieve
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 m
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. Actuall
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
34 matches
Mail list logo