ELPA: New package: svg-lib

ELPA: New package: svg-lib

[Nicolas P. Rougier (inria)]

Dear all,

I would like to submit a new package to ELPA which is a library 
for generating various SVG tags, progress bars, progress pies & 
icons that fits nicely in a text buffer.

The library is hosted at https://github.com/rougier/svg-lib and 
the README displays what it looks like.

Note that there is still a pending bug with text size for some 
users (see https://github.com/rougier/svg-tag-mode/pull/14. This 
is a different project but the problem is the same). Any help 
appreciated.


Best,
Nicolas

Re: ELPA: New package: svg-lib

[Stefan Kangas]

"Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:

> I would like to submit a new package to ELPA which is a library
> for generating various SVG tags, progress bars, progress pies &
> icons that fits nicely in a text buffer.

Full disclosure: I recently asked Nicolas to consider submitting his
package to GNU ELPA.  He had already planned to do that, though:

    https://github.com/rougier/svg-lib/issues/9

I obviously think it's a good addition.

AFAICT, the copyright papers are all in order.  Nicolas has signed them,
and the 3 other contributors to the repository they have fewer than 15
lines each.  (I don't know if any of them have also signed the papers.)

Re: ELPA: New package: svg-lib

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 234 bytes --]

"Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:

> The library is hosted at https://github.com/rougier/svg-lib and
> the README displays what it looks like.

I've attached svg-lib.el below to make reviewing it easier.

[-- Attachment #2: svg-lib.el --]
[-- Type: application/emacs-lisp, Size: 24080 bytes --]

Re: ELPA: New package: svg-lib

[Alan Third]

On Mon, Sep 27, 2021 at 03:49:16PM +0200, Nicolas P. Rougier (inria) wrote:
> 
> Note that there is still a pending bug with text size for some users (see
> https://github.com/rougier/svg-tag-mode/pull/14. This is a different project
> but the problem is the same). Any help appreciated.

Hi Nicolas,

I had my own go at matching SVG images and Emacs's text rendering at
one time and my code is here:

    https://gist.github.com/alanthird/7b86dc66df1ed3b9006bcd3fddd7350f

I was really just messing about, though, so it's probably not much
use.

Reading through that bug report I'm not 100% sure what is going on,
but I do suspect there may be some confusion as the behaviour of SVG
rendering has changed between Emacs 27 and Emacs 28.

For the most part Emacs 28 _should_ do the right thing. i.e. 1em
matches the exact font size used at the insertion point and the
default font family should also match the font at the insertion point.
Emacs 28 also adds the ability to set image sizes with '(1 . em), to
make it easier to make images scale with the font (we're using that to
display checkboxes in customize, and so on).

It also should set the DPI accurately so that 1cm == 1 real world cm,
except possibly on Macs where Apple's recommended DPI behaviour is...

Strange.

Unfortunately I guess you still have to support Emacs 27 (and below?)
so perhaps none of that really helps you.

When generating images I'd suggest always setting the image scale to
1, as that avoids any strange resizing behaviour that may be caused by
the image creation code attempting to rescale images to match the font
size.

Finally we have a bug open about screen DPIs (bug#49937) although it
probably has nothing to do with the problems you're seeing.
-- 
Alan Third

Re: ELPA: New package: svg-lib

[Nicolas P. Rougier (inria)]

Thanks for the information and the code. I did not know about the 
difference between Emacs 27 and 28. I did not have a change to 
test 28.

My problem can be tested with the code below. The goal is to 
output an "A" using SVG and compare it to a regular "A". Ideally, 
they would need to be the same with very minor differences (due to 
different aliasing). But for some users and for unknown reason, 
the svg text size is plainly wrong.

Can you confirm this code works as expected with emacs 28 ? 

#+BEGIN_SRC emacs-lisp

;; To adapt font weight:
;; '((thin       . 100) (ultralight . 200) (light      . 300)
;;   (regular    . 400) (medium     . 500) (semibold   . 600)
;;   (bold       . 700) (extrabold  . 800) (black      . 900))))

(let* ((w           (window-font-width))
       (h           (window-font-height))
       (font        (query-font (font-at (point-min))))
       (font-family (face-attribute 'default :family))
       (font-size   (elt font 2))
       (descent     (elt font 4))
       (svg (svg-create w h)))
  ;; (svg-rectangle svg 0 0 w h :stroke "black" :fill "none")
  (svg-text svg "A"
            :x           0
            :y           descent
            :font-family font-family 
            :font-weight 300
            :font-size   font-size
            :fill        (face-attribute 'default :foreground))
  (insert-image (svg-image svg :ascent 'center)))

#+END_SRC

Nicolas

Alan Third <alan@idiocy.org> writes:

> On Mon, Sep 27, 2021 at 03:49:16PM +0200, Nicolas P. Rougier 
> (inria) wrote:
>> 
>> Note that there is still a pending bug with text size for some 
>> users (see
>> https://github.com/rougier/svg-tag-mode/pull/14. This is a 
>> different project
>> but the problem is the same). Any help appreciated.
>
> Hi Nicolas,
>
> I had my own go at matching SVG images and Emacs's text 
> rendering at
> one time and my code is here:
>
>     https://gist.github.com/alanthird/7b86dc66df1ed3b9006bcd3fddd7350f
>
> I was really just messing about, though, so it's probably not 
> much
> use.
>
> Reading through that bug report I'm not 100% sure what is going 
> on,
> but I do suspect there may be some confusion as the behaviour of 
> SVG
> rendering has changed between Emacs 27 and Emacs 28.
>
> For the most part Emacs 28 _should_ do the right thing. i.e. 1em
> matches the exact font size used at the insertion point and the
> default font family should also match the font at the insertion 
> point.
> Emacs 28 also adds the ability to set image sizes with '(1 
> . em), to
> make it easier to make images scale with the font (we're using 
> that to
> display checkboxes in customize, and so on).
>
> It also should set the DPI accurately so that 1cm == 1 real 
> world cm,
> except possibly on Macs where Apple's recommended DPI behaviour 
> is...
>
> Strange.
>
> Unfortunately I guess you still have to support Emacs 27 (and 
> below?)
> so perhaps none of that really helps you.
>
> When generating images I'd suggest always setting the image 
> scale to
> 1, as that avoids any strange resizing behaviour that may be 
> caused by
> the image creation code attempting to rescale images to match 
> the font
> size.
>
> Finally we have a bug open about screen DPIs (bug#49937) 
> although it
> probably has nothing to do with the problems you're seeing.

Re: ELPA: New package: svg-lib

[Stefan Monnier]

Nicolas P. Rougier (inria) [2021-09-27 15:49:16] wrote:
> generating various SVG tags, progress bars, progress pies & icons that fits
> nicely in a text buffer.
>
> The library is hosted at https://github.com/rougier/svg-lib and the README
> displays what it looks like.

Looks good to me.  Before I add it, tho:

- Please make sure (from now on) that contributors have signed paperwork
  (or that the sum of their contributions stays within the "trivial"
  limit) before you accept their patches.

- The svg-lib-demo.el lacks a `;; Copyright (C) 2021 Free Software Foundation, Inc.`

Also, see below the warnings I got when trying to byte-compile it.
And while I'm here I'd recommend allowing the users to *load* svg-lib.el
even if (not (image-type-available-p 'svg)) and only signal an error
when they actually use the library.


        Stefan


% make packages/svg-lib
emacs --batch -Q -l admin/elpa-admin.el \
         -f elpaa-batch-pkg-spec-make-dependencies .pkg-descs.mk
Generating description file packages/svg-lib/svg-lib-pkg.el
emacs --batch -l admin/elpa-admin.el                               \
         -f elpaa-batch-generate-autoloads packages/svg-lib/svg-lib-autoloads.el
  INFO     Scraping files for svg-lib-autoloads.el... 
  INFO     Scraping files for svg-lib-autoloads.el...done
Byte compiling packages/svg-lib/svg-lib-demo.el
Unable to activate package ‘tuareg’.
Required package ‘caml-3.12.0.1’ is unavailable
Unable to activate package ‘use-package’.
Required package ‘bind-key-2.4’ is unavailable
Unable to activate package ‘modus-vivendi-theme’.
Required package ‘modus-themes-1.2.4’ is unavailable
Unable to activate package ‘modus-operandi-theme’.
Required package ‘modus-themes-1.2.4’ is unavailable

In toplevel form:
packages/svg-lib/svg-lib-demo.el:41:3:Warning: reference to free variable
    ‘GNU’
packages/svg-lib/svg-lib-demo.el:41:7:Warning: reference to free variable
    ‘Emacs’
Byte compiling packages/svg-lib/svg-lib.el
Unable to activate package ‘tuareg’.
Required package ‘caml-3.12.0.1’ is unavailable
Unable to activate package ‘use-package’.
Required package ‘bind-key-2.4’ is unavailable
Unable to activate package ‘modus-vivendi-theme’.
Required package ‘modus-themes-1.2.4’ is unavailable
Unable to activate package ‘modus-operandi-theme’.
Required package ‘modus-themes-1.2.4’ is unavailable

In toplevel form:
packages/svg-lib/svg-lib.el:91:1:Warning: defcustom for
    ‘svg-lib-icon-collections’ provides redundant :group
packages/svg-lib/svg-lib.el:115:1:Warning: defcustom for ‘svg-lib-icons-dir’
    provides redundant :group
packages/svg-lib/svg-lib.el:152:1:Warning: defcustom for
    ‘svg-lib-style-default’ provides redundant :group

In svg-lib-style:
packages/svg-lib/svg-lib.el:177:44:Warning: Unused lexical variable `value'

In svg-lib-tag:
packages/svg-lib/svg-lib.el:214:40:Warning: Unused lexical variable `width'
packages/svg-lib/svg-lib.el:217:40:Warning: Unused lexical variable `scale'
packages/svg-lib/svg-lib.el:229:33:Warning: Unused lexical variable
    `tag-char-height'

In svg-lib-progress-pie:
packages/svg-lib/svg-lib.el:267:40:Warning: Unused lexical variable `width'
packages/svg-lib/svg-lib.el:269:40:Warning: Unused lexical variable `scale'
packages/svg-lib/svg-lib.el:274:40:Warning: Unused lexical variable
    `font-weight'
packages/svg-lib/svg-lib.el:280:66:Warning: Unused lexical variable `ascent'
packages/svg-lib/svg-lib.el:281:33:Warning: Unused lexical variable
    `tag-char-width'
packages/svg-lib/svg-lib.el:282:33:Warning: Unused lexical variable
    `tag-char-height'
packages/svg-lib/svg-lib.el:289:27:Warning: Unused lexical variable `tag-x'
packages/svg-lib/svg-lib.el:299:33:Warning: reference to free variable ‘pi’

In svg-lib-progress-bar:
packages/svg-lib/svg-lib.el:340:40:Warning: Unused lexical variable `scale'
packages/svg-lib/svg-lib.el:345:40:Warning: Unused lexical variable
    `font-weight'
packages/svg-lib/svg-lib.el:351:66:Warning: Unused lexical variable `ascent'
packages/svg-lib/svg-lib.el:352:33:Warning: Unused lexical variable
    `tag-char-width'
packages/svg-lib/svg-lib.el:353:33:Warning: Unused lexical variable
    `tag-char-height'

In svg-lib-icon:
packages/svg-lib/svg-lib.el:427:40:Warning: Unused lexical variable
    `font-size'
packages/svg-lib/svg-lib.el:428:40:Warning: Unused lexical variable
    `font-family'
packages/svg-lib/svg-lib.el:429:40:Warning: Unused lexical variable
    `font-weight'
packages/svg-lib/svg-lib.el:444:20:Warning: string-to-number quoted with '
    rather than with #'
packages/svg-lib/svg-lib.el:471:35:Warning: Unused lexical variable `fill'

In svg-lib-button:
packages/svg-lib/svg-lib.el:508:28:Warning: Unused lexical variable
    `box-width'
packages/svg-lib/svg-lib.el:509:36:Warning: Unused lexical variable
    `box-height'
packages/svg-lib/svg-lib.el:515:33:Warning: Unused lexical variable
    `tag-char-height'
packages/svg-lib/svg-lib.el:557:35:Warning: Unused lexical variable `fill'

In end of data:
packages/svg-lib/svg-lib.el:167:18:Warning: the function ‘color-rgb-to-hex’ is
    not known to be defined.

Re: ELPA: New package: svg-lib

[Alan Third]

On Mon, Sep 27, 2021 at 08:03:12PM +0200, Nicolas P. Rougier (inria) wrote:
> 
> Thanks for the information and the code. I did not know about the difference
> between Emacs 27 and 28. I did not have a change to test 28.
> 
> My problem can be tested with the code below. The goal is to output an "A"
> using SVG and compare it to a regular "A". Ideally, they would need to be
> the same with very minor differences (due to different aliasing). But for
> some users and for unknown reason, the svg text size is plainly wrong.
> 
> Can you confirm this code works as expected with emacs 28 ?
> 
> #+BEGIN_SRC emacs-lisp
> 
> ;; To adapt font weight:
> ;; '((thin       . 100) (ultralight . 200) (light      . 300)
> ;;   (regular    . 400) (medium     . 500) (semibold   . 600)
> ;;   (bold       . 700) (extrabold  . 800) (black      . 900))))
> 
> (let* ((w           (window-font-width))
>       (h           (window-font-height))
>       (font        (query-font (font-at (point-min))))
>       (font-family (face-attribute 'default :family))
>       (font-size   (elt font 2))
>       (descent     (elt font 4))
>       (svg (svg-create w h)))
>  ;; (svg-rectangle svg 0 0 w h :stroke "black" :fill "none")
>  (svg-text svg "A"
>            :x           0
>            :y           descent
>            :font-family font-family            :font-weight 300
>            :font-size   font-size
>            :fill        (face-attribute 'default :foreground))
>  (insert-image (svg-image svg :ascent 'center)))
> 
> #+END_SRC

It's very close. It looks almost completely identical under GNUstep,
but under GTK it looks like the SVG text is sometimes about one pixel
taller, which makes it look slightly different at the default size
(14, I think?) but at larger sizes it looks near identical.

I suspect the difference I'm seeing is simply down to different font
rendering backends.

I'm not using hi-dpi, but even setting GDK_SCALE=2 doesn't make any
difference.

FWIW, I believe that librsvg defaults to 96dpi, however I'm not sure
that it always did, I've a feeling it used to use something different,
so different versions of librsvg may use different default DPIs. Only
Emacs 28 explicitly sets a DPI, so Emacs 27 will use whatever is
default for librsvg.

I ended up using pixels for font sizes rather than trying to get point
sizes to match up. When I DID try to use point sizes, on macOS I had
to multiply every size by something like 72/96. That calculation would
vary with OS and GUI toolkit, and possibly monitor size too.

-- 
Alan Third

Re: ELPA: New package: svg-lib

[Nicolas P. Rougier (inria)]

Alan Third <alan@idiocy.org> writes:

> FWIW, I believe that librsvg defaults to 96dpi, however I'm not 
> sure
> that it always did, I've a feeling it used to use something 
> different,
> so different versions of librsvg may use different default 
> DPIs. Only
> Emacs 28 explicitly sets a DPI, so Emacs 27 will use whatever is
> default for librsvg.

If librsvg changed its default DPI, that would explain why some 
users get a wrong result depending on their lib version.

> I ended up using pixels for font sizes rather than trying to get 
> point
> sizes to match up. When I DID try to use point sizes, on macOS I 
> had
> to multiply every size by something like 72/96. That calculation 
> would
> vary with OS and GUI toolkit, and possibly monitor size too.

I went down this road too and remember having tested the 72/96 
ratio without much success.
More specifically, I try to compute the actual screen dpi and 
adapt the font size but it did not work so well.

Nicolas

Re: ELPA: New package: svg-lib

[Nicolas P. Rougier (inria)]

Thanks for the report. I've fixed most of them and let you know 
when everythign is fixed.

May I ask how you get such detailed report on the byte 
compilation? Mine output is much smaller and do not report 
everything (I simply used the byte-compile-file).

Nicolas

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Nicolas P. Rougier (inria) [2021-09-27 15:49:16] wrote:
>> generating various SVG tags, progress bars, progress pies & 
>> icons that fits
>> nicely in a text buffer.
>>
>> The library is hosted at https://github.com/rougier/svg-lib and 
>> the README
>> displays what it looks like.
>
> Looks good to me.  Before I add it, tho:
>
> - Please make sure (from now on) that contributors have signed 
> paperwork
>   (or that the sum of their contributions stays within the 
>   "trivial"
>   limit) before you accept their patches.
>
> - The svg-lib-demo.el lacks a `;; Copyright (C) 2021 Free 
> Software Foundation, Inc.`
>
> Also, see below the warnings I got when trying to byte-compile 
> it.
> And while I'm here I'd recommend allowing the users to *load* 
> svg-lib.el
> even if (not (image-type-available-p 'svg)) and only signal an 
> error
> when they actually use the library.
>
>
>         Stefan
>
>
> % make packages/svg-lib
> emacs --batch -Q -l admin/elpa-admin.el \
>          -f elpaa-batch-pkg-spec-make-dependencies .pkg-descs.mk
> Generating description file packages/svg-lib/svg-lib-pkg.el
> emacs --batch -l admin/elpa-admin.el 
> \
>          -f elpaa-batch-generate-autoloads 
>          packages/svg-lib/svg-lib-autoloads.el
>   INFO     Scraping files for svg-lib-autoloads.el... 
>   INFO     Scraping files for svg-lib-autoloads.el...done
> Byte compiling packages/svg-lib/svg-lib-demo.el
> Unable to activate package ‘tuareg’.
> Required package ‘caml-3.12.0.1’ is unavailable
> Unable to activate package ‘use-package’.
> Required package ‘bind-key-2.4’ is unavailable
> Unable to activate package ‘modus-vivendi-theme’.
> Required package ‘modus-themes-1.2.4’ is unavailable
> Unable to activate package ‘modus-operandi-theme’.
> Required package ‘modus-themes-1.2.4’ is unavailable
>
> In toplevel form:
> packages/svg-lib/svg-lib-demo.el:41:3:Warning: reference to free 
> variable
>     ‘GNU’
> packages/svg-lib/svg-lib-demo.el:41:7:Warning: reference to free 
> variable
>     ‘Emacs’
> Byte compiling packages/svg-lib/svg-lib.el
> Unable to activate package ‘tuareg’.
> Required package ‘caml-3.12.0.1’ is unavailable
> Unable to activate package ‘use-package’.
> Required package ‘bind-key-2.4’ is unavailable
> Unable to activate package ‘modus-vivendi-theme’.
> Required package ‘modus-themes-1.2.4’ is unavailable
> Unable to activate package ‘modus-operandi-theme’.
> Required package ‘modus-themes-1.2.4’ is unavailable
>
> In toplevel form:
> packages/svg-lib/svg-lib.el:91:1:Warning: defcustom for
>     ‘svg-lib-icon-collections’ provides redundant :group
> packages/svg-lib/svg-lib.el:115:1:Warning: defcustom for 
> ‘svg-lib-icons-dir’
>     provides redundant :group
> packages/svg-lib/svg-lib.el:152:1:Warning: defcustom for
>     ‘svg-lib-style-default’ provides redundant :group
>
> In svg-lib-style:
> packages/svg-lib/svg-lib.el:177:44:Warning: Unused lexical 
> variable `value'
>
> In svg-lib-tag:
> packages/svg-lib/svg-lib.el:214:40:Warning: Unused lexical 
> variable `width'
> packages/svg-lib/svg-lib.el:217:40:Warning: Unused lexical 
> variable `scale'
> packages/svg-lib/svg-lib.el:229:33:Warning: Unused lexical 
> variable
>     `tag-char-height'
>
> In svg-lib-progress-pie:
> packages/svg-lib/svg-lib.el:267:40:Warning: Unused lexical 
> variable `width'
> packages/svg-lib/svg-lib.el:269:40:Warning: Unused lexical 
> variable `scale'
> packages/svg-lib/svg-lib.el:274:40:Warning: Unused lexical 
> variable
>     `font-weight'
> packages/svg-lib/svg-lib.el:280:66:Warning: Unused lexical 
> variable `ascent'
> packages/svg-lib/svg-lib.el:281:33:Warning: Unused lexical 
> variable
>     `tag-char-width'
> packages/svg-lib/svg-lib.el:282:33:Warning: Unused lexical 
> variable
>     `tag-char-height'
> packages/svg-lib/svg-lib.el:289:27:Warning: Unused lexical 
> variable `tag-x'
> packages/svg-lib/svg-lib.el:299:33:Warning: reference to free 
> variable ‘pi’
>
> In svg-lib-progress-bar:
> packages/svg-lib/svg-lib.el:340:40:Warning: Unused lexical 
> variable `scale'
> packages/svg-lib/svg-lib.el:345:40:Warning: Unused lexical 
> variable
>     `font-weight'
> packages/svg-lib/svg-lib.el:351:66:Warning: Unused lexical 
> variable `ascent'
> packages/svg-lib/svg-lib.el:352:33:Warning: Unused lexical 
> variable
>     `tag-char-width'
> packages/svg-lib/svg-lib.el:353:33:Warning: Unused lexical 
> variable
>     `tag-char-height'
>
> In svg-lib-icon:
> packages/svg-lib/svg-lib.el:427:40:Warning: Unused lexical 
> variable
>     `font-size'
> packages/svg-lib/svg-lib.el:428:40:Warning: Unused lexical 
> variable
>     `font-family'
> packages/svg-lib/svg-lib.el:429:40:Warning: Unused lexical 
> variable
>     `font-weight'
> packages/svg-lib/svg-lib.el:444:20:Warning: string-to-number 
> quoted with '
>     rather than with #'
> packages/svg-lib/svg-lib.el:471:35:Warning: Unused lexical 
> variable `fill'
>
> In svg-lib-button:
> packages/svg-lib/svg-lib.el:508:28:Warning: Unused lexical 
> variable
>     `box-width'
> packages/svg-lib/svg-lib.el:509:36:Warning: Unused lexical 
> variable
>     `box-height'
> packages/svg-lib/svg-lib.el:515:33:Warning: Unused lexical 
> variable
>     `tag-char-height'
> packages/svg-lib/svg-lib.el:557:35:Warning: Unused lexical 
> variable `fill'
>
> In end of data:
> packages/svg-lib/svg-lib.el:167:18:Warning: the function 
> ‘color-rgb-to-hex’ is
>     not known to be defined.

Re: ELPA: New package: svg-lib

[Stefan Kangas]

"Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:

> May I ask how you get such detailed report on the byte
> compilation? Mine output is much smaller and do not report
> everything (I simply used the byte-compile-file).

Did you try byte-compiling with current master (the upcoming Emacs
28.1)?  That might explain the difference, as we've added several
warnings.

Re: ELPA: New package: svg-lib

[Stefan Monnier]

> Thanks for the report. I've fixed most of them and let you know when
> everythign is fixed.

I see you fixed the copyright which is the only one that mattered, so
I pushed it, thanks.  Should appear in GNU ELPA as soon as you bump the
`Version:` header (the commit which introduced the `Version: 1.0` still
had problematic copyright info, which will prevent building that
tarball).

> May I ask how you get such detailed report on the byte compilation?

The spurious "Required package ‘<foobar>’ is unavailable" were
graciously provided by some bugs in my config, the likes of "refs to
free var" and the "unused var" should come from `make packages/svg-lib`
(which basically compiles each file in a fresh Emacs session in batch
mode), and some others come from local hacks I have in my personal
branch of Emacs.


        Stefan

Re: ELPA: New package: svg-lib

[Adam Porter]

Hi Nicolas,

"Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:

> May I ask how you get such detailed report on the byte compilation?
> Mine output is much smaller and do not report everything (I simply
> used the byte-compile-file).

FYI, you might find this script helpful for testing and linting Elisp
packages:

https://github.com/alphapapa/makem.sh

It can be used in "M-x compile", from a shell, in GitHub CI, etc.

Re: ELPA: New package: svg-lib

[Nicolas P. Rougier (inria)]

Thanks. Not tried yet, but I will.

Nicolas

Stefan Kangas <stefankangas@gmail.com> writes:

> Did you try byte-compiling with current master (the upcoming 
> Emacs
> 28.1)?  That might explain the difference, as we've added 
> several
> warnings.

Re: ELPA: New package: svg-lib

[Nicolas P. Rougier (inria)]

Thanks.

Nicolas

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Thanks for the report. I've fixed most of them and let you know 
>> when
>> everythign is fixed.
>
> I see you fixed the copyright which is the only one that 
> mattered, so
> I pushed it, thanks.  Should appear in GNU ELPA as soon as you 
> bump the
> `Version:` header (the commit which introduced the `Version: 
> 1.0` still
> had problematic copyright info, which will prevent building that
> tarball).
>
>> May I ask how you get such detailed report on the byte 
>> compilation?
>
> The spurious "Required package ‘<foobar>’ is unavailable" were
> graciously provided by some bugs in my config, the likes of 
> "refs to
> free var" and the "unused var" should come from `make 
> packages/svg-lib`
> (which basically compiles each file in a fresh Emacs session in 
> batch
> mode), and some others come from local hacks I have in my 
> personal
> branch of Emacs.
>
>
>         Stefan