[cairo] cairo Digest, Vol 96, Issue 14

[Kemin Zhou]

With regards to surface backends, I am still having trouble compiling Pango.  
Thanks for the help from this mailing list for compiling the Cairo package.

When I configure Pango, it complains that I don't have usable back ends for Cairo.
I successfully installed Free Type 2 fonts.  When checking the config.log file for Pango, it seems that I still need two things with Cairo.

The error message:
checking for CAIRO... yes
checking which cairo font backends could be used... none
configure: Disabling cairo support
configure: error: *** Could not enable any backends.
*** Must have at least one backend to build Pango.

Has been posted by many people on the internet.  I don't see a good solution.
When I tried the quarz with cairo, it asked for another package that I have no clue where to get it. 

The harfbuzz can be downloaded but cannot be made because a make file bug, when it was looking for the glibc-2.0 that was apparently in the LDFLAGS macro in the Makefile, but somehow this harfbuzz package is not using it when doing the linking.  If any one has some experience, please let me know.





>________________________________
> From: "cairo-request at cairographics.org" <cairo-request at cairographics.org>
>To: cairo at cairographics.org 
>Sent: Thursday, July 11, 2013 12:01 PM
>Subject: cairo Digest, Vol 96, Issue 14
> 
>
>Send cairo mailing list submissions to
>    cairo at cairographics.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>    http://lists.cairographics.org/mailman/listinfo/cairo
>or, via email, send a message with subject or body 'help' to
>    cairo-request at cairographics.org
>
>You can reach the person managing the list at
>    cairo-owner at cairographics.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of cairo digest..."
>
>
>Today's Topics:
>
>   1. Re: support for external surface backends (Matt Sealey)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Wed, 10 Jul 2013 16:21:24 -0500
>From: Matt Sealey <neko at bakuhatsu.net>
>To: Sebastian Reichel <sre at ring0.de>
>Cc: cairo at cairographics.org
>Subject: Re: [cairo] support for external surface backends
>Message-ID:
>    <CAHCPf3sJ0spCsp4pdTnAjnD3+1SphFVeCGUB1QUhtMjh8=zCFw at mail.gmail.com>
>Content-Type: text/plain; charset=ISO-8859-1
>
>On Mon, Jul 8, 2013 at 5:57 PM, Sebastian Reichel <sre at ring0.de> wrote:
>> Hi,
>>
>> We have a Chinese lasercutter at our hackspace, which uses some
>> obscure proprietary format. We are currently reverse engineering
>> the protocol and have written a simple tool, which translates the
>> format into svg using cairo. So far so easy :)
>>
>> But we also want to support translating the other way around. For
>> this we thought about hooking into cairo as surface backend like
>> this:
>>
>> -----
>> cairo_surface_t *surface;
>> cairo_t *cr;
>>
>> surface = laser_cutter_surface_not_part_of_cairo(some, params);
>> cr = cairo_create(surface);
>>
>> do_some_cairo_stuff();
>> -----
>>
>> The backend does not really fit into a default cairo installation
>> and IMHO it does not fit into the cairo repository at all. Thus
>> we would like to put it into an additional library, which implements
>> the surface interface.
>>
>> The problem is, that the cairo API does not allow external surface
>> backends if I'm not mistaken. I mainly see two reasons for this:
>>
>> 1. cairo_surface_type_t is a compile-time-generated enum in cairo's
>>    sourcecode
>> 2. cairo_surface_t and cairo_backend_t are not exposed in the
>>    public API
>>
>> Are there any plans to make these kind of setups possible with
>> cairo?
>
>I never saw any plans but I'd be pleased to suggest a route to doing
>it. I think cairo should support loadable backends - it would go to
>solve this problem and also to mitigate the strange features that if
>you compile in a backend to libcairo suddenly you end up with shared
>dependencies. Any app wanting to use simple image surfaces or xlib
>surfaces on a system with cairo compiled to use GLES suddenly then is
>implicitly linked to GLES, EGL (maybe VG) and so on, which is rather
>an odd circumstance (the net effect is that on the Ubuntu systems I
>run, for example, building Cairo to use GLES means the entire GLES
>stack ends up in the initramfs because of Plymouth's dependency on
>libcairo - but Plymouth doesn't use Cairo EGL or GLES backends)
>
>I don't advocate making externally developed backends available,
>though, that requires fixing down a surface API and exposing it.
>Having a patch which integrates your backend then building Cairo for
>yourself should suffice, though. What should happen is when you try
>and create a surface, cairo knows which backend to load at that point,
>loads it (and pulls in dependencies if it's using dlopen) and then the
>backend will work - or not. In the case it does not load, cairo can
>essentially fail creating a surface on that backend.
>
>Cairo backend detection is already supported by being broken into
>separate pkgconfig files but the backends themselves are not separate,
>soaking memory and dynamic linker time (and as above, maybe space
>which increases boot time) which should probably eventually get
>solved. Applications can know at THEIR build time which backends are
>installed via pkgconfig so they should basically not be calling
>backends without detecting their installation, and at runtime only the
>relevant backends would be loaded for each application as per
>build-time requirement of that application (by virtue of a
>context/surface init).
>
>Someone would need to map out the interdependency of initializing a
>backend and what might be missing in the indirect functions associated
>with it that need to be split.
>
>Matt Sealey <neko at bakuhatsu.net>
>
>
>------------------------------
>
>_______________________________________________
>cairo mailing list
>cairo at cairographics.org
>http://lists.cairographics.org/mailman/listinfo/cairo
>
>End of cairo Digest, Vol 96, Issue 14
>*************************************
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20130711/1ae28ff6/attachment-0001.html>