To follow up, here is a subsequent patch for cl-pdf which smooths things out a bit more (I'm attaching both the 0001 patch and the 0002 patch).
Soon I will send a patch to the cl-typesetting list also, which implements a similar fix for cl-typesetting. On Wed, Mar 27, 2013 at 12:45 AM, Dave Cooper <david.coo...@genworks.com>wrote: > > Hi Marc, > > Thank you for the feedback. > > Ok, here is my proposed patch for this issue. It defers the loading of > fonts in chart.lisp until runtime, and adds a file zzinit.lisp which > contains an initialize! function as well as a confirmation (with warning) > if any of the *afm-files-directories* do not exist. This confirmation is > invoked at the toplevel so you will see a warning during compile and/or > load if the afm directories are not existing, with suggestion to run the > initialize! function at runtime before trying to use cl-pdf functions. > > This patch was made with > > git format-patch > > so you should be able to apply it to a local clone of the master branch > with > > git apply 0001-Make-it-so-cl-pdf-can-load-without-afm-directory-the.patch > > > > > On Tue, Mar 26, 2013 at 11:04 PM, Marc Battyani < > marc.batty...@fractalconcept.com> wrote: > >> Hi Dave, >> >> >> On 26/3/13 21:49 , Dave Cooper wrote: >> >> 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!" : ) >> >> Well I have no idea either and I have to look at how this works on >> github. Anyway this mailing list on common-lisp.net works well and is >> really low volume so probably it's not useful to change for now. That said >> I would be interested to here if people have more informed opinions on that. >> >> 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. >> >> Seems good for me. Anyway as you mentioned, probably everybody had to >> integrate that into some initialization function. >> >> Best Regards >> >> Dave >> >> P.S. Are there plans to bring cl-typesetting to github as well, >> side-by-side with cl-pdf? >> >> Sure! I wanted to clean them up somewhat like I have done with cl-pdf but >> maybe I should move all this to github and clean it later. >> I'm also planning to modernize my web framework and put it on github too >> but this will take some time. >> >> Cheers, >> >> Marc >> >> >>
0001-Make-it-so-cl-pdf-can-load-without-afm-directory-the.patch
Description: Binary data
0002-make-it-so-you-can-load-without-afm-directory.patch
Description: Binary data
_______________________________________________ cl-pdf-devel site list cl-pdf-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/cl-pdf-devel
