[cl-pdf-devel] compile and load-time dependency on *cl-pdf-base-directory* considered harmful (was: Re: cl-pdf is moving to github)

Dave Cooper david.cooper at genworks.com
Wed Mar 27 01:49:48 UTC 2013


Hi All,

 I'm not sure if I should put this on this mailing list or as an Issue on
the new Github site (where I could claim "First!" : )

How many of you have seen this error at some point during your time using
cl-pdf:

 "Error: Font Helvetica not Found"

As you probably know, one of the things which can cause this is when cl-pdf
is being loaded from a compiled fasl which is not in the location of the
source codebase, and the source codebase is no longer available at the
location where it was during compiling.

So my basic question is: does anyone have suggestions what to do about
*cl-pdf-base-directory* and *cl-typesetting-base-directory* so that a fasl
or built runtime can be used without the depending on the original absolute
pathname to afm/ directory, etc. still existing as they were during
compilation? As it is currently, the full hardcoded pathname of the
*cl-pdf-base-directory* and *cl-typesetting-base-directory* are baked into
a compiled fasl. I understand this used to work from *load-truename*
instead of *compile-file-truename*, and the hardcoding of compile-time
source location was introduced as a "fix" for the fact that ASDF started
using output-translations which resulted in the fasl being loaded not being
in the source location. But this "fix" still assumes that the sources are
always going to be available in their original location every time a fasl
is loaded, which I consider to be a fragile assumption.

For me, the ideal solution would be:

 1. First of all, don't have any compile-time or load-time dependencies on
these variables at all. As it is now, only chart.lisp in cl-pdf appears to
depend on *afm-files-directories* -- couldn't this stuff be deferred to
runtime? For cl-typesetting I'm not sure what are the dependencies at
compile and load time, but I speculate that they are few.

 2. Provide an "initialize!" function for use at runtime startup, which is
supposed to establish base directory locations for afm/ directory etc.


Then it would be (as it rightfully should be) the responsibility of any
runtime application which is using cl-pdf to set the *-base-directory*
variables and call the initialize! function as part of its "restart"
function, much the same way as many applications normally have to
initialize themselves at startup to find the location of outside resources
(e.g. webserver applications have to be set with the location of static
files for publishing, etc).

Before I go any deeper into this direction I just wanted to get any
feedback that current users have about this issue. And let me know if it
should be opened as an Issue on the github project or stay on this mailing
list.

Best Regards

 Dave

P.S. Are there plans to bring cl-typesetting to github as well,
side-by-side with cl-pdf?




On Thu, Feb 28, 2013 at 12:28 PM, Marc Battyani <
marc.battyani at fractalconcept.com> wrote:

>  Hi all,
>
> cl-pdf is moving to https://github.com/mbattyani/cl-pdf.git
>
> Please contact me if want to have push access.
>
> Marc
>
>
> _______________________________________________
> cl-pdf-devel site list
> cl-pdf-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/cl-pdf-devel
>



-- 
My Best,

Dave Cooper, Genworks Support
david.cooper at genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cl-pdf-devel/attachments/20130326/5bd9a28c/attachment.html>


More information about the cl-pdf-devel mailing list