From david.cooper at genworks.com Wed Mar 27 01:49:48 2013 From: david.cooper at genworks.com (Dave Cooper) Date: Tue, 26 Mar 2013 21:49:48 -0400 Subject: [cl-pdf-devel] compile and load-time dependency on *cl-pdf-base-directory* considered harmful (was: Re: cl-pdf is moving to github) Message-ID: 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: From marc.battyani at fractalconcept.com Wed Mar 27 03:04:43 2013 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Tue, 26 Mar 2013 23:04:43 -0400 Subject: [cl-pdf-devel] compile and load-time dependency on *cl-pdf-base-directory* considered harmful (was: Re: cl-pdf is moving to github) In-Reply-To: References: Message-ID: <515261CB.3090602@fractalconcept.com> 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 > > On Thu, Feb 28, 2013 at 12:28 PM, Marc Battyani > > 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: From david.cooper at genworks.com Wed Mar 27 04:45:04 2013 From: david.cooper at genworks.com (Dave Cooper) Date: Wed, 27 Mar 2013 00:45:04 -0400 Subject: [cl-pdf-devel] compile and load-time dependency on *cl-pdf-base-directory* considered harmful (was: Re: cl-pdf is moving to github) In-Reply-To: <515261CB.3090602@fractalconcept.com> References: <515261CB.3090602@fractalconcept.com> Message-ID: 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.battyani at 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 > > > 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 > > > -- 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-it-so-cl-pdf-can-load-without-afm-directory-the.patch Type: application/octet-stream Size: 5098 bytes Desc: not available URL: From david.cooper at genworks.com Thu Mar 28 19:15:27 2013 From: david.cooper at genworks.com (Dave Cooper) Date: Thu, 28 Mar 2013 15:15:27 -0400 Subject: [cl-pdf-devel] compile and load-time dependency on *cl-pdf-base-directory* considered harmful (was: Re: cl-pdf is moving to github) In-Reply-To: References: <515261CB.3090602@fractalconcept.com> Message-ID: 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 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.battyani at 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 >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-it-so-cl-pdf-can-load-without-afm-directory-the.patch Type: application/octet-stream Size: 5079 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-make-it-so-you-can-load-without-afm-directory.patch Type: application/octet-stream Size: 1783 bytes Desc: not available URL: From david.cooper at genworks.com Thu Mar 28 19:31:54 2013 From: david.cooper at genworks.com (Dave Cooper) Date: Thu, 28 Mar 2013 15:31:54 -0400 Subject: [cl-pdf-devel] Patch to make it so cl-typesetting can be loaded without hyphenation-patterns/ directory in known location Message-ID: Dear Marc/All, In followup to my recent patch proposals for cl-pdf, here is a similar patch for cl-typesetting which allows the library to be loaded even if cl-pdf's afm/ and cl-typesetting's hyphen-patterns/ directories are not in the standard/known locations at compile and/or load time. For this case, an initialize! function is provided where you can specify these directories and have things set up at runtime initialization time. Feedback welcome (maybe Marc B is waiting for some feedback from the list before he considers going ahead and applying the patches). cl-typesetting is not in git yet, so this patch was made with diff -rupN cl-typesetting/ cl-typesetting-...patched/ so I think it would be applied to a local working directory with cd cl-typesetting/ patch -p1 < cl-typesetting-make-it-so-you-can-load-without-hyphen-patterns.patch -- 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: cl-typesetting-make-it-so-you-can-load-without-hyphen-patterns.patch Type: application/octet-stream Size: 4867 bytes Desc: not available URL: From marc.battyani at fractalconcept.com Thu Mar 28 19:50:46 2013 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Thu, 28 Mar 2013 15:50:46 -0400 Subject: [cl-pdf-devel] compile and load-time dependency on *cl-pdf-base-directory* considered harmful (was: Re: cl-pdf is moving to github) In-Reply-To: References: <515261CB.3090602@fractalconcept.com> Message-ID: <51549F16.9060705@fractalconcept.com> ThanksDavid, I will merge that patch and the cl-typesetting one tomorrow and I will also push cl-typesetting to github at the same time. 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 > > 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 > > 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 > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.battyani at fractalconcept.com Sat Mar 30 04:39:31 2013 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Sat, 30 Mar 2013 00:39:31 -0400 Subject: [cl-pdf-devel] compile and load-time dependency on *cl-pdf-base-directory* considered harmful (was: Re: cl-pdf is moving to github) In-Reply-To: References: <515261CB.3090602@fractalconcept.com> Message-ID: <51566C83.5090607@fractalconcept.com> 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 > > 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 > > 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 > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.battyani at fractalconcept.com Sat Mar 30 04:47:20 2013 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Sat, 30 Mar 2013 00:47:20 -0400 Subject: [cl-pdf-devel] [cl-typesetting-devel] Patch to make it so cl-typesetting can be loaded without hyphenation-patterns/ directory in known location In-Reply-To: References: Message-ID: <51566E58.2020600@fractalconcept.com> Hi Dave, I committed this to the svn cl-typesetting repos. Tomorrow I will move cl-typesetting to github like cl-pdf. Thanks! Marc On 28/3/13 15:31 , Dave Cooper wrote: > > Dear Marc/All, > > In followup to my recent patch proposals for cl-pdf, here is a similar > patch for cl-typesetting which allows the library to be loaded even if > cl-pdf's afm/ and cl-typesetting's hyphen-patterns/ directories are > not in the standard/known locations at compile and/or load time. For > this case, an initialize! function is provided where you can specify > these directories and have things set up at runtime initialization time. > > Feedback welcome (maybe Marc B is waiting for some feedback from the > list before he considers going ahead and applying the patches). > > cl-typesetting is not in git yet, so this patch was made with > > diff -rupN cl-typesetting/ cl-typesetting-...patched/ > > so I think it would be applied to a local working directory with > > > cd cl-typesetting/ > patch -p1 < > cl-typesetting-make-it-so-you-can-load-without-hyphen-patterns.patch > > > > -- > 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 > > > _______________________________________________ > cl-typesetting-devel site list > cl-typesetting-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cl-typesetting-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.battyani at fractalconcept.com Sun Mar 31 21:40:37 2013 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Sun, 31 Mar 2013 17:40:37 -0400 Subject: [cl-pdf-devel] cl-pdf has moved to github In-Reply-To: <51566C83.5090607@fractalconcept.com> References: <515261CB.3090602@fractalconcept.com> <51566C83.5090607@fractalconcept.com> Message-ID: <5158AD55.20400@fractalconcept.com> Dear all, cl-pdf has moved to https://github.com/mbattyani/cl-pdf cl-typesetting has moved to https://github.com/mbattyani/cl-typesetting cl-typegraph now has its own repository at https://github.com/mbattyani/cl-typegraph Marc From ungil at mac.com Sun Mar 31 21:52:41 2013 From: ungil at mac.com (Carlos Ungil) Date: Sun, 31 Mar 2013 23:52:41 +0200 Subject: [cl-pdf-devel] cl-pdf multi-platform support Message-ID: Hello, I was able to make cl-pdf work on many lisps (tested on macos and windows only) using the following definitions for +external-format+ and *default-charset* in config.lisp (CMUCL is not listed explicitly, but it works as well): (defconstant +external-format+ #-(or sbcl lispworks clisp allegro ccl abcl ecl) :default #+abcl '(:iso-8859-1 :eol-style :lf) #+ecl '(:latin-1 :lf) #+ccl :latin1 #+sbcl :latin-1 #+allegro :octets #+lispworks '(:latin-1 :eol-style :lf) #+clisp (ext:make-encoding :charset 'charset:iso-8859-1 :line-terminator :unix)) (defvar *default-charset* #+(and lispworks5 win32) (ef::ef-coded-character-set win32:*multibyte-code-page-ef*) #-(and lispworks5 win32) *char-single-byte-codes*) ; last resort It seems that the form #+clisp (setf *default-file-encoding* ...) be safely removed. By the way, the code recently added to set data directories at runtime raises an error in clisp (probe-file can't handle directories on that platform). Adding :use-salza2-zlib to *features* compressed files can be created in all the implementations (ECL tested only on macos) if string-to-octets is defined in zlib.lisp as follows: #+use-salza2-zlib (defun string-to-octets (string start end) "Convert STRING to a sequence of octets, if possible." (declare (type string string) (type buffer-offset start end) (optimize (speed 3) (safety 0))) #+(and sbcl (not octet-characters)) (sb-ext:string-to-octets string :external-format :iso-8859-1 :start start :end end) #+(and allegro (not octet-characters)) (excl:string-to-octets string :external-format :octets :start start :end end :null-terminate nil) #+(and clisp (not octet-characters)) (ext:convert-string-to-bytes string custom:*default-file-encoding* :start start :end end) #+(and ccl (not octet-characters)) (ccl:encode-string-to-octets string :external-format :latin-1 :start start :end end) #+(and cmu (not octet-characters)) (ext:string-to-octets string :external-format :iso-8859-1 :start start :end end) #+(or octet-characters lispworks abcl ecl) (let* ((length (- end start)) (result (make-array length :element-type 'salza2::octet))) (loop for i fixnum from start below end for j fixnum from 0 do (setf (aref result j) (char-code (aref string i)))) result) #+(and (not octet-characters) (not (or sbcl allegro clisp ccl cmu lispworks abcl ecl))) (error "Do not know how to convert a string to octets.")) ECL support requires as well making a couple of changes to pdf.lisp to make the conditionals #+allegro, #-allegro refer to (or allegro ecl) instead: #-(or allegro ecl) ;; line 575 (defmethod write-document ((filename pathname) &optional (document *document*)) #+(or allegro ecl) ;; line 585 (defmethod write-document ((filename pathname) &optional (document *document*)) I also found a minor bug in example10 (the write-document is inside the dolist loop): examples/examples.lisp @@ -551,5 +551,5 @@ (apply #'pdf:set-rgb-fill (hsv->rgb (/ x 9.1) 1 1)) (pdf:set-transparency (/ y 9.0) bm) (pdf:circle (* x 50) (* y 80) 30) - (pdf:fill-path)))))) - (pdf:write-document file)))) + (pdf:fill-path))))))) + (pdf:write-document file))) Best regards, Carlos From marc.battyani at fractalconcept.com Sun Mar 31 23:47:49 2013 From: marc.battyani at fractalconcept.com (Marc Battyani) Date: Sun, 31 Mar 2013 19:47:49 -0400 Subject: [cl-pdf-devel] cl-pdf multi-platform support In-Reply-To: References: Message-ID: <5158CB25.5080202@fractalconcept.com> Hi Carlos, Thanks for your compatibility fixes. I pushed them to github. Marc On 31/3/13 17:52 , Carlos Ungil wrote: > Hello, > > I was able to make cl-pdf work on many lisps (tested on macos and windows only) using the following definitions for +external-format+ and *default-charset* in config.lisp (CMUCL is not listed explicitly, but it works as well): > > (defconstant +external-format+ > #-(or sbcl lispworks clisp allegro ccl abcl ecl) :default > #+abcl '(:iso-8859-1 :eol-style :lf) > #+ecl '(:latin-1 :lf) > #+ccl :latin1 > #+sbcl :latin-1 > #+allegro :octets > #+lispworks '(:latin-1 :eol-style :lf) > #+clisp (ext:make-encoding :charset 'charset:iso-8859-1 :line-terminator :unix)) > > (defvar *default-charset* > #+(and lispworks5 win32) (ef::ef-coded-character-set win32:*multibyte-code-page-ef*) > #-(and lispworks5 win32) *char-single-byte-codes*) ; last resort > > It seems that the form #+clisp (setf *default-file-encoding* ...) be safely removed. By the way, the code recently added to set data directories at runtime raises an error in clisp (probe-file can't handle directories on that platform). > > > Adding :use-salza2-zlib to *features* compressed files can be created in all the implementations (ECL tested only on macos) if string-to-octets is defined in zlib.lisp as follows: > > #+use-salza2-zlib > (defun string-to-octets (string start end) > "Convert STRING to a sequence of octets, if possible." > (declare (type string string) > (type buffer-offset start end) > (optimize (speed 3) (safety 0))) > #+(and sbcl (not octet-characters)) > (sb-ext:string-to-octets string :external-format :iso-8859-1 :start start :end end) > #+(and allegro (not octet-characters)) > (excl:string-to-octets string :external-format :octets :start start :end end :null-terminate nil) > #+(and clisp (not octet-characters)) > (ext:convert-string-to-bytes string custom:*default-file-encoding* :start start :end end) > #+(and ccl (not octet-characters)) > (ccl:encode-string-to-octets string :external-format :latin-1 :start start :end end) > #+(and cmu (not octet-characters)) > (ext:string-to-octets string :external-format :iso-8859-1 :start start :end end) > #+(or octet-characters lispworks abcl ecl) > (let* ((length (- end start)) > (result (make-array length :element-type 'salza2::octet))) > (loop for i fixnum from start below end > for j fixnum from 0 > do (setf (aref result j) (char-code (aref string i)))) > result) > #+(and (not octet-characters) (not (or sbcl allegro clisp ccl cmu lispworks abcl ecl))) > (error "Do not know how to convert a string to octets.")) > > > ECL support requires as well making a couple of changes to pdf.lisp to make the conditionals #+allegro, #-allegro refer to (or allegro ecl) instead: > > #-(or allegro ecl) ;; line 575 > (defmethod write-document ((filename pathname) &optional (document *document*)) > > #+(or allegro ecl) ;; line 585 > (defmethod write-document ((filename pathname) &optional (document *document*)) > > > I also found a minor bug in example10 (the write-document is inside the dolist loop): > examples/examples.lisp > @@ -551,5 +551,5 @@ > (apply #'pdf:set-rgb-fill (hsv->rgb (/ x 9.1) 1 1)) > (pdf:set-transparency (/ y 9.0) bm) > (pdf:circle (* x 50) (* y 80) 30) > - (pdf:fill-path)))))) > - (pdf:write-document file)))) > + (pdf:fill-path))))))) > + (pdf:write-document file))) > > > Best regards, > > Carlos > _______________________________________________ > cl-pdf-devel site list > cl-pdf-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cl-pdf-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: