Hi Dave, I committed this to the github cl-pdf repos. Thanks!
Marc On 28/3/13 15:15 , Dave Cooper wrote: > > > 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 <mailto: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 > <mailto: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 > <http://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 > >>
_______________________________________________ cl-pdf-devel site list cl-pdf-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/cl-pdf-devel
