Re: [PATCH 02/48] Added new icon build rule
Joel Holdsworth writes: > In this solution you have a single page with multiple icon images present. You > then place on top of these images "magic" invisible rectangles which have been > tagged so that the renderer script knows to treat these as boundary boxes. For > wine's purposes, you would then need embed to the canvas any raster images and > tag these in a similar way which instructs the renderer to decode the base64 > into a files. Multiple vector rendering would then combine together with > multiple raster images unpacked, and these would be bundled into an ico. > > The great advantage is that inkscape supports this stuff today, so it's not so > bad for artists. > > How does that sound? I would have to see what the Wine side scripts would look like, but it sounds promising. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 02/48] Added new icon build rule
Ok, I have good news and bad news. The good news is that multipage is standard now in SVG 1.2, and it is possible to embed a raster image in the SVG if you encode it in base64. Embedded images are partially supported in inkscape via python extensions. The bad news is that you can't set the canvas sizes of individual pages - only the orientation. Ideally we would set the bounding box of each page. One solution would be to set the canvas size to some arbitrary size, then tag the individual pages with custom attributes from some kind of wine namespace extension, that would tell the renderer what boundary box to draw with, and what bit depth to sample to. The alternative solution (which I favour) would be a one canvas workflow, which some Tango artists are using. This was the approach I took when I was making icons for Lumiera: http://www.lumiera.org/gitweb?p=lumiera/ichthyo;a=blob_plain;f=icons/svg/tool-arrow.svg;hb=HEAD In this solution you have a single page with multiple icon images present. You then place on top of these images "magic" invisible rectangles which have been tagged so that the renderer script knows to treat these as boundary boxes. For wine's purposes, you would then need embed to the canvas any raster images and tag these in a similar way which instructs the renderer to decode the base64 into a files. Multiple vector rendering would then combine together with multiple raster images unpacked, and these would be bundled into an ico. The great advantage is that inkscape supports this stuff today, so it's not so bad for artists. How does that sound? Joel
Re: [PATCH 02/48] Added new icon build rule
> I'm certainly open to suggestions on how to reduce the work needed for > the first step, but it needs to be a step in the right direction. Adding > 500 files and reorganizing many directories is not a good intermediate > measure. I definitely want your work committed too, in fact I included > it in the requirements for the 1.2 release; but I'm not willing to make > a mess of the source tree just to get this in sooner, as I'm sure you > understand. Ok, thanks for letting me know. I'll investigate multipage SVG and see what I can come up with All the best Joel
Re: [PATCH 02/48] Added new icon build rule
Joel Holdsworth writes: > Speaking personally: This project has already taken me over a year to get this > far, and after all this painstaking work I'm really keen to get it out to the > world, but I'm so short of time right now, and it feels like every time I try > and submit, there are more of these never ending hoops to jump through. From > my > perspective I won't abandon this work that I've spent so much time on, but > it's > becoming this never ending nightmare of obstacles. I'm looking at the big > picture and wondering; is turning a very minor mess of 9 files into 1 per icon > really the best use of my time, when I could be productively contributing to > areas of need within the FOSS world that will have a real effect on FOSS > users. > > I want to keep pursuing this and I respect your opinion very much as the > veteron > maintainer of this project. Your uncompromising comittment to quality has > resulted in an excellent and long standing project, it's just that I'm finding > the lack of flexibility quite hard to cope with. Is there no way we could > compromise on this? I'm certainly open to suggestions on how to reduce the work needed for the first step, but it needs to be a step in the right direction. Adding 500 files and reorganizing many directories is not a good intermediate measure. I definitely want your work committed too, in fact I included it in the requirements for the 1.2 release; but I'm not willing to make a mess of the source tree just to get this in sooner, as I'm sure you understand. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 02/48] Added new icon build rule
Hi Joel, I'm piping up not because I can speak for Alexandre--I can't--but to express that you're not the only one interested in seeing this work merged. > It is possible with a multipage SVG (which Inkscape doesn't support yet, and > can't be rendered RSVG) and embedded bitmaps for the hand tweaked images > (which are at beta stage AFAIK). That's bad news, but these obstacles can be > overcome by me spending a lot of my time (which these days is in really > short supply) writing scripts in Perl, but that would require me to use Perl > (which I don't know and would have to learn)*, and could take several more > months. You could also ask for help. I too am not a Perl hacker, but there are some on list. > It would also require a dependancy on some kind of command line image > handling tool like ImageMagick or Python image stuff (which I'm sure you > won't like) because RSVG only renders to 32-bit, but we need to output to > 4-bit and 8-bit without screwing up these palette (which may be very hard). ImageMagick, at least, is very commonly available. In my personal opinion, adding a dependency on it to build the icons doesn't seem onerous. We have stranger requirements elsewhere in the build. > The end result would be 1 file rather than 9, but in a format which is > harder even than ico for artists to work with given the state of todays > tools. Perhaps, but assuming a script to generate .icos from the SVG exists, it seems that a mirror script to create the SVG from its source files mightn't be too hard. Given such a script, artists wouldn't need to reinvent that particular wheel, and at some point the need for it should disappear (assuming Inkscape implements support for multipage SVGs.) > * I do use python though - is there any in the project? There isn't. > Speaking personally: This project has already taken me over a year to get > this far, and after all this painstaking work I'm really keen to get it out > to the world, but I'm so short of time right now, and it feels like every > time I try and submit, there are more of these never ending hoops to jump > through. From my perspective I won't abandon this work that I've spent so > much time on, but it's becoming this never ending nightmare of obstacles. > I'm looking at the big picture and wondering; is turning a very minor mess > of 9 files into 1 per icon really the best use of my time, when I could be > productively contributing to areas of need within the FOSS world that will > have a real effect on FOSS users. We feel your pain ;-) Think of it this way: assuming you take the time to do this right, the next contributor won't have as steep an obstacle to deal with. You're not just contributing artwork--which are much appreciated, believe me--you're improving the workflow for future artists. Cheers, --Juan
Re: [PATCH 02/48] Added new icon build rule
On 22 March 2010 at 15:37 Alexandre Julliard wrote: > Joel Holdsworth writes: > > >> I still think that having to commit 10 source files per icon is not > >> acceptable, even with subdirectories. > > I agree it is a lot of source files, but I don't see that that's a problem > > if > > they're stored neatly within a resources subdirectory. user32.dll has a lot > > of > > images, but that's not a problem for this reason. In fact by creating > > resources > > subdirectories surely I'm tidying? because it unclutters the mix of > > resources > > and source code in many dlls. > > > > The issue is that the 9 images are never going to go away - a full XP icon > > has > > at least 9 independant hand crafted images to go into it. Vista and 7 icons > > have > > even more. > > As far as I understand it's possible to store everything in a single SVG > file. I don't know if tools like inkscape can support this directly, but > it's all XML so a simple perl wrapper should be able to do anything we > need. It is possible with a multipage SVG (which Inkscape doesn't support yet, and can't be rendered RSVG) and embedded bitmaps for the hand tweaked images (which are at beta stage AFAIK). That's bad news, but these obstacles can be overcome by me spending a lot of my time (which these days is in really short supply) writing scripts in Perl, but that would require me to use Perl (which I don't know and would have to learn)*, and could take several more months. It would also require a dependancy on some kind of command line image handling tool like ImageMagick or Python image stuff (which I'm sure you won't like) because RSVG only renders to 32-bit, but we need to output to 4-bit and 8-bit without screwing up these palette (which may be very hard). The end result would be 1 file rather than 9, but in a format which is harder even than ico for artists to work with given the state of todays tools. * I do use python though - is there any in the project? Speaking personally: This project has already taken me over a year to get this far, and after all this painstaking work I'm really keen to get it out to the world, but I'm so short of time right now, and it feels like every time I try and submit, there are more of these never ending hoops to jump through. From my perspective I won't abandon this work that I've spent so much time on, but it's becoming this never ending nightmare of obstacles. I'm looking at the big picture and wondering; is turning a very minor mess of 9 files into 1 per icon really the best use of my time, when I could be productively contributing to areas of need within the FOSS world that will have a real effect on FOSS users. I want to keep pursuing this and I respect your opinion very much as the veteron maintainer of this project. Your uncompromising comittment to quality has resulted in an excellent and long standing project, it's just that I'm finding the lack of flexibility quite hard to cope with. Is there no way we could compromise on this? Joel
Re: [PATCH 02/48] Added new icon build rule
Joel Holdsworth writes: >> I still think that having to commit 10 source files per icon is not >> acceptable, even with subdirectories. > I agree it is a lot of source files, but I don't see that that's a problem if > they're stored neatly within a resources subdirectory. user32.dll has a lot of > images, but that's not a problem for this reason. In fact by creating > resources > subdirectories surely I'm tidying? because it unclutters the mix of resources > and source code in many dlls. > > The issue is that the 9 images are never going to go away - a full XP icon has > at least 9 independant hand crafted images to go into it. Vista and 7 icons > have > even more. As far as I understand it's possible to store everything in a single SVG file. I don't know if tools like inkscape can support this directly, but it's all XML so a simple perl wrapper should be able to do anything we need. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 02/48] Added new icon build rule
> I still think that having to commit 10 source files per icon is not > acceptable, even with subdirectories. I agree it is a lot of source files, but I don't see that that's a problem if they're stored neatly within a resources subdirectory. user32.dll has a lot of images, but that's not a problem for this reason. In fact by creating resources subdirectories surely I'm tidying? because it unclutters the mix of resources and source code in many dlls. The issue is that the 9 images are never going to go away - a full XP icon has at least 9 independant hand crafted images to go into it. Vista and 7 icons have even more. Now the question is what to do about it? The two approaches I can see are to keep them independant and stored neatly, or to package them somehow. Keeping them independant is ideal from the artist's point of view because the SVGs and PNGs can be viewed and editied in their native format. I could package them together into an archive of some sort e.g. an icon.tar.gz file. That would make the build rules easier, but it would mean the individual images could not be individually versioned, and make them slightly harder to edit. An alternative we discused was to use a .ico rather than a .tar.gz as an image repository. However this has several problems: 1. Ugly blurring of the line between source binary and compiled binary: The build rule becomes 1x.ico + 4x.svg -> .ico. Kinda circular. 2. .ico files are a real pain to work with from the artist's point of view. It's a very unusual image format. 3. It's so easy to screw up the icon's internal structure, or change the format of a sub-image without meaning to. Many image editor apps will not generate a byte for byte identical file in an open->edit->save process, and many image editors would subdly change the ico format, and git version history would not make that kind of change clear. 4. Even then you're still left with 4 images - 1x .ico and 3x .svg, so the problem is still pretty bad. I favour the individual images approach, or I could do a package approach if you like, but I can't see how a .ico package could work. Do you see my problem? Joel
Re: [PATCH 02/48] Added new icon build rule
Joel Holdsworth writes: > Sure - I > can understand that. The reason I sent so many was that I wanted to show you > that I don't plan to leave a depreciated SVG build rule lying around. I also > wanted you to see and comment on my approach of creating resources > subdirectories in these dlls like user32 has, and then putting the icon images > in these. > > What do you think? I still think that having to commit 10 source files per icon is not acceptable, even with subdirectories. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 02/48] Added new icon build rule
Alexandre Julliard wrote: > Joel Holdsworth writes: > > > @@ -188,6 +188,11 @@ filter: dummy > > .man.in.man: > > LC_ALL=C sed -e 's,@bindir\@,$(bindir),g' -e > >'s,@dlldir\@,$(dlldir),g' -e 's,@PACKAGE_STRING\@,@PACKAGE_STRING@,g' $< >$@ > >|| ($(RM) $@ && false) > > > > +# Rules for icons > > + > > +ifdef SVG_SRCS > > + > > +# Depreciated icon build rule > > .svg.ico: > > $(RSVG) -w 16 -h 16 -f png $< $*-16.png > > $(RSVG) -w 32 -h 32 -f png $< $*-32.png > > @@ -195,6 +200,17 @@ filter: dummy > > $(ICOTOOL) -c -o $@ $*-16.png $*-32.png $*-48.png > > $(RM) $*-16.png $*-32.png $*-48.png > > > > +else > > + > > +resources/%-32.png: resources/%.svg > > + $(RSVG) -f png $< $@ > > + > > +resources/%.ico : resources/%-*-4.png resources/%-*-8.png \ > > + resources/%-16-32.png resources/%-32-32.png resources/%-48-32.png > > + $(ICOTOOL) -c -o $@ $^ > > + > > +endif > > That's GNU make specific, you can't do that. Yes I wondered if that might be the case. Do you (or anyone) have any thoughts about how to approach this? The .svg.ico suffix rule that's present at the moment works if there's a 1:1 relationship; one svg results in one ico. My problem is that a 9:1 relationship is required. Do you have any suggestions about how to make a generic rule to do that? Does it require changes to makedep? > Also please don't send such a huge patch series. The first step should > be to get just one icon committed with the proper infrastructure. Then > you can consider sending more of them, preferably one dll at a time.Sure - I > can understand that. The reason I sent so many was that I wanted to show you > that I don't plan to leave a depreciated SVG build rule lying around. I also > wanted you to see and comment on my approach of creating resources > subdirectories in these dlls like user32 has, and then putting the icon images > in these. What do you think? Joel Holdsworth
Re: [PATCH 02/48] Added new icon build rule
Joel Holdsworth writes: > @@ -188,6 +188,11 @@ filter: dummy > .man.in.man: > LC_ALL=C sed -e 's,@bindir\@,$(bindir),g' -e 's,@dlldir\@,$(dlldir),g' > -e 's,@PACKAGE_STRING\@,@PACKAGE_STRING@,g' $< >$@ || ($(RM) $@ && false) > > +# Rules for icons > + > +ifdef SVG_SRCS > + > +# Depreciated icon build rule > .svg.ico: > $(RSVG) -w 16 -h 16 -f png $< $*-16.png > $(RSVG) -w 32 -h 32 -f png $< $*-32.png > @@ -195,6 +200,17 @@ filter: dummy > $(ICOTOOL) -c -o $@ $*-16.png $*-32.png $*-48.png > $(RM) $*-16.png $*-32.png $*-48.png > > +else > + > +resources/%-32.png: resources/%.svg > + $(RSVG) -f png $< $@ > + > +resources/%.ico : resources/%-*-4.png resources/%-*-8.png \ > +resources/%-16-32.png resources/%-32-32.png resources/%-48-32.png > + $(ICOTOOL) -c -o $@ $^ > + > +endif That's GNU make specific, you can't do that. Also please don't send such a huge patch series. The first step should be to get just one icon committed with the proper infrastructure. Then you can consider sending more of them, preferably one dll at a time. -- Alexandre Julliard julli...@winehq.org
