Menu
▾
▴
rails-devel
|
From: Erik V. <eri...@xs...> - 2011-06-03 18:56:50
|
This stuff is mostly new to me, but on a first look into Batik, I wonder if we could use the Batik Swing interface. Should we change the map into a JSVGCanvas? Or two? Because, to achieve displaying the map *below* the tiles, I had to insert a JLayeredPane, with the map on layer -1 (bottom) and the tiles on layer 0 (top). Without that layered pane, it turned out the other way around (don't know why). Erik P.S. I changed the subject of this thread. > -----Oorspronkelijk bericht----- > Van: brett lentz [mailto:bre...@gm...] > Verzonden: vrijdag 3 juni 2011 19:28 > Aan: Development list for Rails: an 18xx game > Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised > version) > > I have a feeling that old drawing code is just incredibly inefficient and adding > the map might tip it over into unusability. I'll blame my limited understanding > of AWT. It's probably time to refactor a bunch of that. ;-) > > Some possible places to look for improvements: > > 1. It looks like we're still using AffineTransforms on the rasterized version of > the hex. (A remnant from when we were still using GIF-based tiles. There is > likely a way to get Batik to manipulate the vector-based format prior to > rasterization in a more efficient way. > > Once we rasterize the image, we should avoid changing it. > > 2. There may be a better way to load the map than with > BufferedImageTranscoder. > > 3. Profiling the code will likely help quickly locate the reason drawing is slow. > It looks like there's some profiling plugins available for Eclipse ( > http://www.eclipse.org/tptp/home/downloads/ ), but I'm not sure how well > they work. > > Though, simply adding a few debugging statements starting at paint() or > paintComponent() might be sufficient to see how often they're called in a > single rendering. It might just be a simple issue of repainting the window > more often than we really need to. > > > ---Brett. > > > > On Fri, Jun 3, 2011 at 9:02 AM, Erik Vos <eri...@xs...> wrote: > > OK, I have attached a patch file that includes all differences. Hope it's not > too big... > > The main part is a trimmed version of the 18EU map, with all empty borders > removed (by Inkscape). > > I did that in the hope that it would help fixing the crash problem, but it > didn't help at all. But in any case I think it's better to avoid such empty > borders. > > > > Erik. > > > >> -----Oorspronkelijk bericht----- > >> Van: brett lentz [mailto:bre...@gm...] > >> Verzonden: vrijdag 3 juni 2011 16:54 > >> Aan: Development list for Rails: an 18xx game > >> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised > >> version) > >> > >> On Fri, Jun 3, 2011 at 5:43 AM, Erik Vos <eri...@xs...> wrote: > >> > I would like to give other people a chance to play with this new > >> > stuff, but I'm not sure if I should commit my changes to the SVN > >> > trunk. Perhaps we should create a branch for this experimental > >> > feature (but I have no clue how to do that - I've never done > >> branching before). > >> > On the other hand, I have already added a configuration property to > >> > completely suppress the use of SVG maps, so probably no harm would > >> > be done by putting this code into the trunk anyway. > >> > > >> > Suggestions? > >> > > >> > >> Post your implementation to the list as a set of diffs. Perhaps just > >> a second set of eyes can help spot the issue. > >> > >> > Erik. > >> > >> ---Brett. > >> > >> --------------------------------------------------------------------- > >> --------- Simplify data backup and recovery for your virtual > >> environment with vRanger. > >> Installation's a snap, and flexible recovery options mean your data > >> is safe, secure and there when you need it. Discover what all the > cheering's about. > >> Get your free trial download today. > >> http://p.sf.net/sfu/quest-dev2dev2 > >> _______________________________________________ > >> Rails-devel mailing list > >> Rai...@li... > >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > ---------------------------------------------------------------------- > > -------- Simplify data backup and recovery for your virtual > > environment with vRanger. > > Installation's a snap, and flexible recovery options mean your data is > > safe, secure and there when you need it. Discover what all the cheering's > about. > > Get your free trial download today. > > http://p.sf.net/sfu/quest-dev2dev2 > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with > vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Discover what all the cheering's about. > Get your free trial download today. > http://p.sf.net/sfu/quest-dev2dev2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: brett l. <bre...@gm...> - 2011-06-03 18:59:36
|
That sounds like a very possible option. If we can let Batik handle all of the image processing internally, that sounds like a win to me. ---Brett. On Fri, Jun 3, 2011 at 11:56 AM, Erik Vos <eri...@xs...> wrote: > This stuff is mostly new to me, but on a first look into Batik, I wonder if we could use the Batik Swing interface. > Should we change the map into a JSVGCanvas? > > Or two? Because, to achieve displaying the map *below* the tiles, I had to insert a JLayeredPane, with the map on layer -1 (bottom) and the tiles on layer 0 (top). Without that layered pane, it turned out the other way around (don't know why). > > Erik > > P.S. I changed the subject of this thread. > >> -----Oorspronkelijk bericht----- >> Van: brett lentz [mailto:bre...@gm...] >> Verzonden: vrijdag 3 juni 2011 19:28 >> Aan: Development list for Rails: an 18xx game >> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised >> version) >> >> I have a feeling that old drawing code is just incredibly inefficient and adding >> the map might tip it over into unusability. I'll blame my limited understanding >> of AWT. It's probably time to refactor a bunch of that. ;-) >> >> Some possible places to look for improvements: >> >> 1. It looks like we're still using AffineTransforms on the rasterized version of >> the hex. (A remnant from when we were still using GIF-based tiles. There is >> likely a way to get Batik to manipulate the vector-based format prior to >> rasterization in a more efficient way. >> >> Once we rasterize the image, we should avoid changing it. >> >> 2. There may be a better way to load the map than with >> BufferedImageTranscoder. >> >> 3. Profiling the code will likely help quickly locate the reason drawing is slow. >> It looks like there's some profiling plugins available for Eclipse ( >> http://www.eclipse.org/tptp/home/downloads/ ), but I'm not sure how well >> they work. >> >> Though, simply adding a few debugging statements starting at paint() or >> paintComponent() might be sufficient to see how often they're called in a >> single rendering. It might just be a simple issue of repainting the window >> more often than we really need to. >> >> >> ---Brett. >> >> >> >> On Fri, Jun 3, 2011 at 9:02 AM, Erik Vos <eri...@xs...> wrote: >> > OK, I have attached a patch file that includes all differences. Hope it's not >> too big... >> > The main part is a trimmed version of the 18EU map, with all empty borders >> removed (by Inkscape). >> > I did that in the hope that it would help fixing the crash problem, but it >> didn't help at all. But in any case I think it's better to avoid such empty >> borders. >> > >> > Erik. >> > >> >> -----Oorspronkelijk bericht----- >> >> Van: brett lentz [mailto:bre...@gm...] >> >> Verzonden: vrijdag 3 juni 2011 16:54 >> >> Aan: Development list for Rails: an 18xx game >> >> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised >> >> version) >> >> >> >> On Fri, Jun 3, 2011 at 5:43 AM, Erik Vos <eri...@xs...> wrote: >> >> > I would like to give other people a chance to play with this new >> >> > stuff, but I'm not sure if I should commit my changes to the SVN >> >> > trunk. Perhaps we should create a branch for this experimental >> >> > feature (but I have no clue how to do that - I've never done >> >> branching before). >> >> > On the other hand, I have already added a configuration property to >> >> > completely suppress the use of SVG maps, so probably no harm would >> >> > be done by putting this code into the trunk anyway. >> >> > >> >> > Suggestions? >> >> > >> >> >> >> Post your implementation to the list as a set of diffs. Perhaps just >> >> a second set of eyes can help spot the issue. >> >> >> >> > Erik. >> >> >> >> ---Brett. >> >> >> >> --------------------------------------------------------------------- >> >> --------- Simplify data backup and recovery for your virtual >> >> environment with vRanger. >> >> Installation's a snap, and flexible recovery options mean your data >> >> is safe, secure and there when you need it. Discover what all the >> cheering's about. >> >> Get your free trial download today. >> >> http://p.sf.net/sfu/quest-dev2dev2 >> >> _______________________________________________ >> >> Rails-devel mailing list >> >> Rai...@li... >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> > >> > ---------------------------------------------------------------------- >> > -------- Simplify data backup and recovery for your virtual >> > environment with vRanger. >> > Installation's a snap, and flexible recovery options mean your data is >> > safe, secure and there when you need it. Discover what all the cheering's >> about. >> > Get your free trial download today. >> > http://p.sf.net/sfu/quest-dev2dev2 >> > _______________________________________________ >> > Rails-devel mailing list >> > Rai...@li... >> > https://lists.sourceforge.net/lists/listinfo/rails-devel >> > >> > >> >> ------------------------------------------------------------------------------ >> Simplify data backup and recovery for your virtual environment with >> vRanger. >> Installation's a snap, and flexible recovery options mean your data is safe, >> secure and there when you need it. Discover what all the cheering's about. >> Get your free trial download today. >> http://p.sf.net/sfu/quest-dev2dev2 >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Discover what all the cheering's about. > Get your free trial download today. > http://p.sf.net/sfu/quest-dev2dev2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Erik V. <eri...@xs...> - 2011-06-06 10:55:45
|
I have found the Batik JSVGCanvas approach to be promising. The main problem is the lack of any good documentation, tutorials or how-to's on the functionality that we need, and the Javadocs aren't very helpful either. After searching during the better part of yesterday, I found some pointers on high Google page numbers that finally put me in the right direction. Some observations: - The 18EU map loads faster, though not at lightning speed. The map is big (~800K), XML parsing is notoriously slow, and I suspect initial SVG rendering also is. - The speed of tile drawing is about back to normal. - Best of all: no more crashes. That really tips the balance for me. - Zooming works, but the zoomed map and tiles do not align yet. Tiles are still drawn the old way, in a different layer, and using separate coordinates. Alignment currently is a trial-and-error exercise that apparently does not survive zooming. The obvious follow-up is to see if tile drawing can also be moved to the JSVGCanvas. I suppose this will amount to manipulating the underlying DOM. I'll probably postpone that until a later stage. My intention is to commit the new code pretty soon (using the map will remain optional). First I want to give post-zooming alignment a few more tries. I'll probably also include Bill Rosgen's suggestions to change hex highlighting. Erik. > -----Oorspronkelijk bericht----- > Van: brett lentz [mailto:bre...@gm...] > Verzonden: vrijdag 3 juni 2011 20:59 > Aan: Development list for Rails: an 18xx game > Onderwerp: Re: [Rails-devel] Background Maps > > That sounds like a very possible option. If we can let Batik handle all of the > image processing internally, that sounds like a win to me. > > ---Brett. > > > > On Fri, Jun 3, 2011 at 11:56 AM, Erik Vos <eri...@xs...> wrote: > > This stuff is mostly new to me, but on a first look into Batik, I wonder if we > could use the Batik Swing interface. > > Should we change the map into a JSVGCanvas? > > > > Or two? Because, to achieve displaying the map *below* the tiles, I had to > insert a JLayeredPane, with the map on layer -1 (bottom) and the tiles on > layer 0 (top). Without that layered pane, it turned out the other way around > (don't know why). > > > > Erik > > > > P.S. I changed the subject of this thread. > > > >> -----Oorspronkelijk bericht----- > >> Van: brett lentz [mailto:bre...@gm...] > >> Verzonden: vrijdag 3 juni 2011 19:28 > >> Aan: Development list for Rails: an 18xx game > >> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised > >> version) > >> > >> I have a feeling that old drawing code is just incredibly inefficient > >> and adding the map might tip it over into unusability. I'll blame my > >> limited understanding of AWT. It's probably time to refactor a bunch > >> of that. ;-) > >> > >> Some possible places to look for improvements: > >> > >> 1. It looks like we're still using AffineTransforms on the > >> rasterized version of the hex. (A remnant from when we were still > >> using GIF-based tiles. There is likely a way to get Batik to > >> manipulate the vector-based format prior to rasterization in a more > efficient way. > >> > >> Once we rasterize the image, we should avoid changing it. > >> > >> 2. There may be a better way to load the map than with > >> BufferedImageTranscoder. > >> > >> 3. Profiling the code will likely help quickly locate the reason drawing is > slow. > >> It looks like there's some profiling plugins available for Eclipse ( > >> http://www.eclipse.org/tptp/home/downloads/ ), but I'm not sure how > >> well they work. > >> > >> Though, simply adding a few debugging statements starting at paint() > >> or > >> paintComponent() might be sufficient to see how often they're called > >> in a single rendering. It might just be a simple issue of repainting > >> the window more often than we really need to. > >> > >> > >> ---Brett. > >> > >> > >> > >> On Fri, Jun 3, 2011 at 9:02 AM, Erik Vos <eri...@xs...> wrote: > >> > OK, I have attached a patch file that includes all differences. > >> > Hope it's not > >> too big... > >> > The main part is a trimmed version of the 18EU map, with all empty > >> > borders > >> removed (by Inkscape). > >> > I did that in the hope that it would help fixing the crash problem, > >> > but it > >> didn't help at all. But in any case I think it's better to avoid > >> such empty borders. > >> > > >> > Erik. > >> > > >> >> -----Oorspronkelijk bericht----- > >> >> Van: brett lentz [mailto:bre...@gm...] > >> >> Verzonden: vrijdag 3 juni 2011 16:54 > >> >> Aan: Development list for Rails: an 18xx game > >> >> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission > >> >> (revised > >> >> version) > >> >> > >> >> On Fri, Jun 3, 2011 at 5:43 AM, Erik Vos <eri...@xs...> wrote: > >> >> > I would like to give other people a chance to play with this new > >> >> > stuff, but I'm not sure if I should commit my changes to the SVN > >> >> > trunk. Perhaps we should create a branch for this experimental > >> >> > feature (but I have no clue how to do that - I've never done > >> >> branching before). > >> >> > On the other hand, I have already added a configuration property > >> >> > to completely suppress the use of SVG maps, so probably no harm > >> >> > would be done by putting this code into the trunk anyway. > >> >> > > >> >> > Suggestions? > >> >> > > >> >> > >> >> Post your implementation to the list as a set of diffs. Perhaps > >> >> just a second set of eyes can help spot the issue. > >> >> > >> >> > Erik. > >> >> > >> >> ---Brett. > >> >> > >> >> ------------------------------------------------------------------ > >> >> --- > >> >> --------- Simplify data backup and recovery for your virtual > >> >> environment with vRanger. > >> >> Installation's a snap, and flexible recovery options mean your > >> >> data is safe, secure and there when you need it. Discover what all > >> >> the > >> cheering's about. > >> >> Get your free trial download today. > >> >> http://p.sf.net/sfu/quest-dev2dev2 > >> >> _______________________________________________ > >> >> Rails-devel mailing list > >> >> Rai...@li... > >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel > >> > > >> > ------------------------------------------------------------------- > >> > --- > >> > -------- Simplify data backup and recovery for your virtual > >> > environment with vRanger. > >> > Installation's a snap, and flexible recovery options mean your data > >> > is safe, secure and there when you need it. Discover what all the > >> > cheering's > >> about. > >> > Get your free trial download today. > >> > http://p.sf.net/sfu/quest-dev2dev2 > >> > _______________________________________________ > >> > Rails-devel mailing list > >> > Rai...@li... > >> > https://lists.sourceforge.net/lists/listinfo/rails-devel > >> > > >> > > >> > >> --------------------------------------------------------------------- > >> --------- Simplify data backup and recovery for your virtual > >> environment with vRanger. > >> Installation's a snap, and flexible recovery options mean your data > >> is safe, secure and there when you need it. Discover what all the > cheering's about. > >> Get your free trial download today. > >> http://p.sf.net/sfu/quest-dev2dev2 > >> _______________________________________________ > >> Rails-devel mailing list > >> Rai...@li... > >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > ---------------------------------------------------------------------- > > -------- Simplify data backup and recovery for your virtual > > environment with vRanger. > > Installation's a snap, and flexible recovery options mean your data is > > safe, secure and there when you need it. Discover what all the cheering's > about. > > Get your free trial download today. > > http://p.sf.net/sfu/quest-dev2dev2 > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with > vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Discover what all the cheering's about. > Get your free trial download today. > http://p.sf.net/sfu/quest-dev2dev2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Adam B. <ab...@o2...> - 2011-06-06 11:08:16
|
I was working on moving entire drawing to SVG (and this was one of the
reasons I tried to push Batik 1.7). But recently my second child was born
and there is some little chaos in my life with not much time for such tasks.
I still have SVN Patch yet it is already conflicting at some places with new
code.
What I managed to get was to create an SVG document containing map (all
the tiles, either from map or track tiles). It looked significantly better
than our previous drawing mechanism. While it was much less and much simpler
code. Also it scaled nicely.
What the code was missing was:
(1) drawing station tokens,
(2) drawing train paths,
(3) handling scaling and scrolling well,
(4) support tile selection.
First two would likely require some "hacking" as there is no easy way
currently to do it in SVG Document as there is not "specification" of tracks
and stations on an SVG tile. But previous code did it somehow and I guess
that solution could be used with SVG Document as well until (if ever) SVG
tiles will receive better description. (That is a topic interesting on its
own...)
I tries to handle third by using JSVGSrolledPane (or something called
similarly) but didn't achieve much. Then I had to interrupt my
investigations.
Fourth should be easy as Batik provides some events to detect this. I
expect this could be even easier then current mouse handling. Borders around
selected or marked tiles could likely be achieved easily with CSS in the SVG
Document.
I can post that Patch if anyone is interested (but not until I'm at
home) especially that I don't know whether I will find time to continue this
work.
Adam Badura
-----Oryginalna wiadomość-----
From: Erik Vos
Sent: Monday, June 06, 2011 12:55 PM
To: 'Development list for Rails: an 18xx game'
Subject: Re: [Rails-devel] Background Maps
I have found the Batik JSVGCanvas approach to be promising. The main
problem is the lack of any good documentation, tutorials or how-to's on the
functionality that we need, and the Javadocs aren't very helpful either.
After searching during the better part of yesterday, I found some pointers
on high Google page numbers that finally put me in the right direction.
Some observations:
- The 18EU map loads faster, though not at lightning speed. The map is big
(~800K), XML parsing is notoriously slow, and I suspect initial SVG
rendering also is.
- The speed of tile drawing is about back to normal.
- Best of all: no more crashes. That really tips the balance for me.
- Zooming works, but the zoomed map and tiles do not align yet. Tiles are
still drawn the old way, in a different layer, and using separate
coordinates. Alignment currently is a trial-and-error exercise that
apparently does not survive zooming.
The obvious follow-up is to see if tile drawing can also be moved to the
JSVGCanvas. I suppose this will amount to manipulating the underlying DOM.
I'll probably postpone that until a later stage.
My intention is to commit the new code pretty soon (using the map will
remain optional). First I want to give post-zooming alignment a few more
tries. I'll probably also include Bill Rosgen's suggestions to change hex
highlighting.
Erik.
> -----Oorspronkelijk bericht-----
> Van: brett lentz [mailto:bre...@gm...]
> Verzonden: vrijdag 3 juni 2011 20:59
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Background Maps
>
> That sounds like a very possible option. If we can let Batik handle all of
> the
> image processing internally, that sounds like a win to me.
>
> ---Brett.
>
>
>
> On Fri, Jun 3, 2011 at 11:56 AM, Erik Vos <eri...@xs...> wrote:
> > This stuff is mostly new to me, but on a first look into Batik, I wonder
> > if we
> could use the Batik Swing interface.
> > Should we change the map into a JSVGCanvas?
> >
> > Or two? Because, to achieve displaying the map *below* the tiles, I had
> > to
> insert a JLayeredPane, with the map on layer -1 (bottom) and the tiles on
> layer 0 (top). Without that layered pane, it turned out the other way
> around
> (don't know why).
> >
> > Erik
> >
> > P.S. I changed the subject of this thread.
> >
> >> -----Oorspronkelijk bericht-----
> >> Van: brett lentz [mailto:bre...@gm...]
> >> Verzonden: vrijdag 3 juni 2011 19:28
> >> Aan: Development list for Rails: an 18xx game
> >> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised
> >> version)
> >>
> >> I have a feeling that old drawing code is just incredibly inefficient
> >> and adding the map might tip it over into unusability. I'll blame my
> >> limited understanding of AWT. It's probably time to refactor a bunch
> >> of that. ;-)
> >>
> >> Some possible places to look for improvements:
> >>
> >> 1. It looks like we're still using AffineTransforms on the
> >> rasterized version of the hex. (A remnant from when we were still
> >> using GIF-based tiles. There is likely a way to get Batik to
> >> manipulate the vector-based format prior to rasterization in a more
> efficient way.
> >>
> >> Once we rasterize the image, we should avoid changing it.
> >>
> >> 2. There may be a better way to load the map than with
> >> BufferedImageTranscoder.
> >>
> >> 3. Profiling the code will likely help quickly locate the reason
> >> drawing is
> slow.
> >> It looks like there's some profiling plugins available for Eclipse (
> >> http://www.eclipse.org/tptp/home/downloads/ ), but I'm not sure how
> >> well they work.
> >>
> >> Though, simply adding a few debugging statements starting at paint()
> >> or
> >> paintComponent() might be sufficient to see how often they're called
> >> in a single rendering. It might just be a simple issue of repainting
> >> the window more often than we really need to.
> >>
> >>
> >> ---Brett.
> >>
> >>
> >>
> >> On Fri, Jun 3, 2011 at 9:02 AM, Erik Vos <eri...@xs...> wrote:
> >> > OK, I have attached a patch file that includes all differences.
> >> > Hope it's not
> >> too big...
> >> > The main part is a trimmed version of the 18EU map, with all empty
> >> > borders
> >> removed (by Inkscape).
> >> > I did that in the hope that it would help fixing the crash problem,
> >> > but it
> >> didn't help at all. But in any case I think it's better to avoid
> >> such empty borders.
> >> >
> >> > Erik.
> >> >
> >> >> -----Oorspronkelijk bericht-----
> >> >> Van: brett lentz [mailto:bre...@gm...]
> >> >> Verzonden: vrijdag 3 juni 2011 16:54
> >> >> Aan: Development list for Rails: an 18xx game
> >> >> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission
> >> >> (revised
> >> >> version)
> >> >>
> >> >> On Fri, Jun 3, 2011 at 5:43 AM, Erik Vos <eri...@xs...> wrote:
> >> >> > I would like to give other people a chance to play with this new
> >> >> > stuff, but I'm not sure if I should commit my changes to the SVN
> >> >> > trunk. Perhaps we should create a branch for this experimental
> >> >> > feature (but I have no clue how to do that - I've never done
> >> >> branching before).
> >> >> > On the other hand, I have already added a configuration property
> >> >> > to completely suppress the use of SVG maps, so probably no harm
> >> >> > would be done by putting this code into the trunk anyway.
> >> >> >
> >> >> > Suggestions?
> >> >> >
> >> >>
> >> >> Post your implementation to the list as a set of diffs. Perhaps
> >> >> just a second set of eyes can help spot the issue.
> >> >>
> >> >> > Erik.
> >> >>
> >> >> ---Brett.
> >> >>
> >> >> ------------------------------------------------------------------
> >> >> ---
> >> >> --------- Simplify data backup and recovery for your virtual
> >> >> environment with vRanger.
> >> >> Installation's a snap, and flexible recovery options mean your
> >> >> data is safe, secure and there when you need it. Discover what all
> >> >> the
> >> cheering's about.
> >> >> Get your free trial download today.
> >> >> http://p.sf.net/sfu/quest-dev2dev2
> >> >> _______________________________________________
> >> >> Rails-devel mailing list
> >> >> Rai...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >
> >> > -------------------------------------------------------------------
> >> > ---
> >> > -------- Simplify data backup and recovery for your virtual
> >> > environment with vRanger.
> >> > Installation's a snap, and flexible recovery options mean your data
> >> > is safe, secure and there when you need it. Discover what all the
> >> > cheering's
> >> about.
> >> > Get your free trial download today.
> >> > http://p.sf.net/sfu/quest-dev2dev2
> >> > _______________________________________________
> >> > Rails-devel mailing list
> >> > Rai...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> --------- Simplify data backup and recovery for your virtual
> >> environment with vRanger.
> >> Installation's a snap, and flexible recovery options mean your data
> >> is safe, secure and there when you need it. Discover what all the
> cheering's about.
> >> Get your free trial download today.
> >> http://p.sf.net/sfu/quest-dev2dev2
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > ----------------------------------------------------------------------
> > -------- Simplify data backup and recovery for your virtual
> > environment with vRanger.
> > Installation's a snap, and flexible recovery options mean your data is
> > safe, secure and there when you need it. Discover what all the
> > cheering's
> about.
> > Get your free trial download today.
> > http://p.sf.net/sfu/quest-dev2dev2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: Erik V. <eri...@xs...> - 2011-06-06 12:44:12
|
Adam, Congratulations with your second child! I'm certainly interested to have a look at your code, to check if I can merge it with my map display code. Some more comments below. > -----Oorspronkelijk bericht----- > Van: Adam Badura [mailto:ab...@o2...] > > I was working on moving entire drawing to SVG (and this was one of the > reasons I tried to push Batik 1.7). But recently my second child was born and > there is some little chaos in my life with not much time for such tasks. > I still have SVN Patch yet it is already conflicting at some places with new > code. > > What I managed to get was to create an SVG document containing map (all > the tiles, either from map or track tiles). It looked significantly better than our > previous drawing mechanism. While it was much less and much simpler code. > Also it scaled nicely. > > What the code was missing was: > (1) drawing station tokens, > (2) drawing train paths, > (3) handling scaling and scrolling well, > (4) support tile selection. > > First two would likely require some "hacking" as there is no easy way > currently to do it in SVG Document as there is not "specification" of tracks > and stations on an SVG tile. But previous code did it somehow and I guess > that solution could be used with SVG Document as well until (if ever) SVG > tiles will receive better description. (That is a topic interesting on its > own...) The tracks and the token spot locations are also (somewhat cryptically) defined in Tiles.xml, and these definitions are currently used to draw the train paths and tokens. For the time being (or perhaps forever) that can be left as is, drawing these objects in the top layer of the JLayeredPane that I'm currently using. However, that would still require achieving correct alignment of the two layers after zooming. > I tries to handle third by using JSVGSrolledPane (or something called > similarly) but didn't achieve much. Then I had to interrupt my investigations. I have also been thinking about JSVGScrolledPane, but I think using that will only become possible once we manage to do all drawing via JSVG. > Fourth should be easy as Batik provides some events to detect this. I > expect this could be even easier then current mouse handling. Borders > around selected or marked tiles could likely be achieved easily with CSS in the > SVG Document. Sounds good. Erik. |
|
From: Adam B. <ab...@o2...> - 2011-06-06 21:46:06
Attachments:
Rails SVG.patch
|
Sorry for the delay but I decided to adapt the patch to current code revision and have a look whether it does what I recall it did. Also I removed some additional works on symbols which I was doing along (this was the reason to start this work) but would be only distracting now. The code is mostly not documented as it is a working patch. Its not also "clean". But it does show that SVG Document isn't that hard. (To scroll or zoom use standard Batik components ways: Shift/Ctrl + moves with mouse buttons pressed.) So what do you think? Should I continue my work in this area? Adam Badura -----Oryginalna wiadomość----- From: Erik Vos Sent: Monday, June 06, 2011 2:43 PM To: 'Development list for Rails: an 18xx game' Subject: Re: [Rails-devel] Background Maps Adam, Congratulations with your second child! I'm certainly interested to have a look at your code, to check if I can merge it with my map display code. Some more comments below. > -----Oorspronkelijk bericht----- > Van: Adam Badura [mailto:ab...@o2...] > > I was working on moving entire drawing to SVG (and this was one of the > reasons I tried to push Batik 1.7). But recently my second child was born > and > there is some little chaos in my life with not much time for such tasks. > I still have SVN Patch yet it is already conflicting at some places with > new > code. > > What I managed to get was to create an SVG document containing map > (all > the tiles, either from map or track tiles). It looked significantly better > than our > previous drawing mechanism. While it was much less and much simpler code. > Also it scaled nicely. > > What the code was missing was: > (1) drawing station tokens, > (2) drawing train paths, > (3) handling scaling and scrolling well, > (4) support tile selection. > > First two would likely require some "hacking" as there is no easy way > currently to do it in SVG Document as there is not "specification" of > tracks > and stations on an SVG tile. But previous code did it somehow and I guess > that solution could be used with SVG Document as well until (if ever) SVG > tiles will receive better description. (That is a topic interesting on its > own...) The tracks and the token spot locations are also (somewhat cryptically) defined in Tiles.xml, and these definitions are currently used to draw the train paths and tokens. For the time being (or perhaps forever) that can be left as is, drawing these objects in the top layer of the JLayeredPane that I'm currently using. However, that would still require achieving correct alignment of the two layers after zooming. > I tries to handle third by using JSVGSrolledPane (or something called > similarly) but didn't achieve much. Then I had to interrupt my > investigations. I have also been thinking about JSVGScrolledPane, but I think using that will only become possible once we manage to do all drawing via JSVG. > Fourth should be easy as Batik provides some events to detect this. I > expect this could be even easier then current mouse handling. Borders > around selected or marked tiles could likely be achieved easily with CSS > in the > SVG Document. Sounds good. Erik. ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: brett l. <bre...@gm...> - 2011-06-07 04:32:14
|
I think this is an excellent direction to continue working on. The patch looks like it consolidates a bunch of code into a couple of classes, which looks good on first glance. I'd definitely like to see the finished patch once you're ready for it to be merged into the codebase. ---Brett. On Mon, Jun 6, 2011 at 2:45 PM, Adam Badura <ab...@o2...> wrote: > Sorry for the delay but I decided to adapt the patch to current code > revision and have a look whether it does what I recall it did. Also I > removed some additional works on symbols which I was doing along (this was > the reason to start this work) but would be only distracting now. > > The code is mostly not documented as it is a working patch. Its not also > "clean". But it does show that SVG Document isn't that hard. (To scroll or > zoom use standard Batik components ways: Shift/Ctrl + moves with mouse > buttons pressed.) > > So what do you think? Should I continue my work in this area? > > Adam Badura > > -----Oryginalna wiadomość----- From: Erik Vos > Sent: Monday, June 06, 2011 2:43 PM > To: 'Development list for Rails: an 18xx game' > Subject: Re: [Rails-devel] Background Maps > > Adam, > > Congratulations with your second child! > > I'm certainly interested to have a look at your code, to check if I can > merge it with my map display code. > > Some more comments below. > >> -----Oorspronkelijk bericht----- >> Van: Adam Badura [mailto:ab...@o2...] >> >> I was working on moving entire drawing to SVG (and this was one of the >> reasons I tried to push Batik 1.7). But recently my second child was born >> and >> there is some little chaos in my life with not much time for such tasks. >> I still have SVN Patch yet it is already conflicting at some places with >> new >> code. >> >> What I managed to get was to create an SVG document containing map (all >> the tiles, either from map or track tiles). It looked significantly better >> than our >> previous drawing mechanism. While it was much less and much simpler code. >> Also it scaled nicely. >> >> What the code was missing was: >> (1) drawing station tokens, >> (2) drawing train paths, >> (3) handling scaling and scrolling well, >> (4) support tile selection. >> >> First two would likely require some "hacking" as there is no easy way >> currently to do it in SVG Document as there is not "specification" of >> tracks >> and stations on an SVG tile. But previous code did it somehow and I guess >> that solution could be used with SVG Document as well until (if ever) SVG >> tiles will receive better description. (That is a topic interesting on its >> own...) > > The tracks and the token spot locations are also (somewhat cryptically) > defined in Tiles.xml, and these definitions are currently used to draw the > train paths and tokens. > For the time being (or perhaps forever) that can be left as is, drawing > these objects in the top layer of the JLayeredPane that I'm currently using. > However, that would still require achieving correct alignment of the two > layers after zooming. > >> I tries to handle third by using JSVGSrolledPane (or something called >> similarly) but didn't achieve much. Then I had to interrupt my >> investigations. > > I have also been thinking about JSVGScrolledPane, but I think using that > will only become possible once we manage to do all drawing via JSVG. > >> Fourth should be easy as Batik provides some events to detect this. I >> expect this could be even easier then current mouse handling. Borders >> around selected or marked tiles could likely be achieved easily with CSS >> in the >> SVG Document. > > Sounds good. > > Erik. > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Discover what all the cheering's about. > Get your free trial download today. > http://p.sf.net/sfu/quest-dev2dev2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: Adam B. <ab...@o2...> - 2011-06-07 05:38:20
|
OK. Great. Then I shell continue this work. Yet I cannot promise when it
will be done. But I will try to report on progress every now and then.
Adam Badura
-----Oryginalna wiadomość-----
From: brett lentz
Sent: Tuesday, June 07, 2011 6:31 AM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Background Maps
I think this is an excellent direction to continue working on.
The patch looks like it consolidates a bunch of code into a couple of
classes, which looks good on first glance.
I'd definitely like to see the finished patch once you're ready for it
to be merged into the codebase.
---Brett.
On Mon, Jun 6, 2011 at 2:45 PM, Adam Badura <ab...@o2...> wrote:
> Sorry for the delay but I decided to adapt the patch to current code
> revision and have a look whether it does what I recall it did. Also I
> removed some additional works on symbols which I was doing along (this was
> the reason to start this work) but would be only distracting now.
>
> The code is mostly not documented as it is a working patch. Its not also
> "clean". But it does show that SVG Document isn't that hard. (To scroll or
> zoom use standard Batik components ways: Shift/Ctrl + moves with mouse
> buttons pressed.)
>
> So what do you think? Should I continue my work in this area?
>
> Adam Badura
>
> -----Oryginalna wiadomość----- From: Erik Vos
> Sent: Monday, June 06, 2011 2:43 PM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] Background Maps
>
> Adam,
>
> Congratulations with your second child!
>
> I'm certainly interested to have a look at your code, to check if I can
> merge it with my map display code.
>
> Some more comments below.
>
>> -----Oorspronkelijk bericht-----
>> Van: Adam Badura [mailto:ab...@o2...]
>>
>> I was working on moving entire drawing to SVG (and this was one of the
>> reasons I tried to push Batik 1.7). But recently my second child was born
>> and
>> there is some little chaos in my life with not much time for such tasks.
>> I still have SVN Patch yet it is already conflicting at some places with
>> new
>> code.
>>
>> What I managed to get was to create an SVG document containing map
>> (all
>> the tiles, either from map or track tiles). It looked significantly
>> better
>> than our
>> previous drawing mechanism. While it was much less and much simpler code.
>> Also it scaled nicely.
>>
>> What the code was missing was:
>> (1) drawing station tokens,
>> (2) drawing train paths,
>> (3) handling scaling and scrolling well,
>> (4) support tile selection.
>>
>> First two would likely require some "hacking" as there is no easy way
>> currently to do it in SVG Document as there is not "specification" of
>> tracks
>> and stations on an SVG tile. But previous code did it somehow and I guess
>> that solution could be used with SVG Document as well until (if ever) SVG
>> tiles will receive better description. (That is a topic interesting on
>> its
>> own...)
>
> The tracks and the token spot locations are also (somewhat cryptically)
> defined in Tiles.xml, and these definitions are currently used to draw the
> train paths and tokens.
> For the time being (or perhaps forever) that can be left as is, drawing
> these objects in the top layer of the JLayeredPane that I'm currently
> using.
> However, that would still require achieving correct alignment of the two
> layers after zooming.
>
>> I tries to handle third by using JSVGSrolledPane (or something called
>> similarly) but didn't achieve much. Then I had to interrupt my
>> investigations.
>
> I have also been thinking about JSVGScrolledPane, but I think using that
> will only become possible once we manage to do all drawing via JSVG.
>
>> Fourth should be easy as Batik provides some events to detect this. I
>> expect this could be even easier then current mouse handling. Borders
>> around selected or marked tiles could likely be achieved easily with CSS
>> in the
>> SVG Document.
>
> Sounds good.
>
> Erik.
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: Stefan F. <ste...@we...> - 2011-08-17 20:40:41
|
Adam & Erik, going back through the archives of mails, which I did not read carefully before, I saw this patch. What happened to it, it seems that it was not applied to the trunk, but maybe it went into a svn branch and was not imported into git? I did not look into the display code too much (only a few fixes until now and the train paths), however even at that time I was surprised that the existing code mainly used standard awt/swing functions instead of the batik svg functionality. The approach of Adam to create a SVG document directly is one way. Another possibility is to create the SVG document indirectly by replacing the Graphics2D implementation with the batik provided SVGGraphics2D engine. This redirects the Java graphics functions to store the output as SVG elements into the SVG document. So questions are: Adam are you still working on this? And what was the reason for you Erik to not following up this direction (most likely many other to- dos)? I imagine that creating a unified SVG document would make the adding alternative GUIs much easier than now. Stefan On Monday, June 06, 2011 11:45:57 pm Adam Badura wrote: > Sorry for the delay but I decided to adapt the patch to current code > revision and have a look whether it does what I recall it did. Also I > removed some additional works on symbols which I was doing along (this was > the reason to start this work) but would be only distracting now. > > The code is mostly not documented as it is a working patch. Its not also > "clean". But it does show that SVG Document isn't that hard. (To scroll or > zoom use standard Batik components ways: Shift/Ctrl + moves with mouse > buttons pressed.) > > So what do you think? Should I continue my work in this area? > > Adam Badura > > -----Oryginalna wiadomość----- > From: Erik Vos > Sent: Monday, June 06, 2011 2:43 PM > To: 'Development list for Rails: an 18xx game' > Subject: Re: [Rails-devel] Background Maps > > Adam, > > Congratulations with your second child! > > I'm certainly interested to have a look at your code, to check if I can > merge it with my map display code. > > Some more comments below. > > > -----Oorspronkelijk bericht----- > > Van: Adam Badura [mailto:ab...@o2...] > > > > I was working on moving entire drawing to SVG (and this was one of > > the > > > > reasons I tried to push Batik 1.7). But recently my second child was born > > and > > there is some little chaos in my life with not much time for such tasks. > > I still have SVN Patch yet it is already conflicting at some places with > > new > > code. > > > > What I managed to get was to create an SVG document containing map > > > > (all > > the tiles, either from map or track tiles). It looked significantly > > better than our > > previous drawing mechanism. While it was much less and much simpler code. > > Also it scaled nicely. > > > > What the code was missing was: > > (1) drawing station tokens, > > (2) drawing train paths, > > (3) handling scaling and scrolling well, > > (4) support tile selection. > > > > First two would likely require some "hacking" as there is no easy way > > > > currently to do it in SVG Document as there is not "specification" of > > tracks > > and stations on an SVG tile. But previous code did it somehow and I guess > > that solution could be used with SVG Document as well until (if ever) SVG > > tiles will receive better description. (That is a topic interesting on > > its own...) > > The tracks and the token spot locations are also (somewhat cryptically) > defined in Tiles.xml, and these definitions are currently used to draw the > train paths and tokens. > For the time being (or perhaps forever) that can be left as is, drawing > these objects in the top layer of the JLayeredPane that I'm currently > using. However, that would still require achieving correct alignment of > the two layers after zooming. > > > I tries to handle third by using JSVGSrolledPane (or something > > called > > > > similarly) but didn't achieve much. Then I had to interrupt my > > investigations. > > I have also been thinking about JSVGScrolledPane, but I think using that > will only become possible once we manage to do all drawing via JSVG. > > > Fourth should be easy as Batik provides some events to detect this. I > > > > expect this could be even easier then current mouse handling. Borders > > around selected or marked tiles could likely be achieved easily with CSS > > in the > > SVG Document. > > Sounds good. > > Erik. > > > --------------------------------------------------------------------------- > --- Simplify data backup and recovery for your virtual environment with > vRanger. Installation's a snap, and flexible recovery options mean your > data is safe, secure and there when you need it. Discover what all the > cheering's about. Get your free trial download today. > http://p.sf.net/sfu/quest-dev2dev2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Adam B. <ab...@o2...> - 2011-08-17 20:49:12
|
In general I do like thinking that I'm working on it. Yet in reality I haven't done anything for a long time now. Mostly due to now 2 children consuming way to much time. ;) (And this requires serious investigations into Java, SVG and Rails itself thus I have to be rather focused and fresh to work on it...) I would not mind anyone taking over the patch especially that I cannot promise when I will do it myself. I could serve with advice or reviewing if that was desired. The patch itself showed only how the map looks like when drawn by providing SVG document. It was far from usable. (No selection, no proper scrolling, no stations, ...) I chose generating SVG document (as XML DOM) based on map and current state (as opposed to drawing through Batik) because: (1) I think it adds a reasonable layer of abstraction. It is much easier to write (and then maintain) code that generates XML then code that draws. (2) I think it is more reusable generally. Such document could be saved and used outside of Rails. (3) I simply like XML. And that was part of my investigations in maintining a better XML+SVG tiles repository for 18xx. -----Oryginalna wiadomość----- From: Stefan Frey Sent: Wednesday, August 17, 2011 10:43 PM To: Development list for Rails: an 18xx game Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps) Adam & Erik, going back through the archives of mails, which I did not read carefully before, I saw this patch. What happened to it, it seems that it was not applied to the trunk, but maybe it went into a svn branch and was not imported into git? I did not look into the display code too much (only a few fixes until now and the train paths), however even at that time I was surprised that the existing code mainly used standard awt/swing functions instead of the batik svg functionality. The approach of Adam to create a SVG document directly is one way. Another possibility is to create the SVG document indirectly by replacing the Graphics2D implementation with the batik provided SVGGraphics2D engine. This redirects the Java graphics functions to store the output as SVG elements into the SVG document. So questions are: Adam are you still working on this? And what was the reason for you Erik to not following up this direction (most likely many other to- dos)? I imagine that creating a unified SVG document would make the adding alternative GUIs much easier than now. Stefan On Monday, June 06, 2011 11:45:57 pm Adam Badura wrote: > Sorry for the delay but I decided to adapt the patch to current code > revision and have a look whether it does what I recall it did. Also I > removed some additional works on symbols which I was doing along (this was > the reason to start this work) but would be only distracting now. > > The code is mostly not documented as it is a working patch. Its not also > "clean". But it does show that SVG Document isn't that hard. (To scroll or > zoom use standard Batik components ways: Shift/Ctrl + moves with mouse > buttons pressed.) > > So what do you think? Should I continue my work in this area? > > Adam Badura > > -----Oryginalna wiadomość----- > From: Erik Vos > Sent: Monday, June 06, 2011 2:43 PM > To: 'Development list for Rails: an 18xx game' > Subject: Re: [Rails-devel] Background Maps > > Adam, > > Congratulations with your second child! > > I'm certainly interested to have a look at your code, to check if I can > merge it with my map display code. > > Some more comments below. > > > -----Oorspronkelijk bericht----- > > Van: Adam Badura [mailto:ab...@o2...] > > > > I was working on moving entire drawing to SVG (and this was one of > > the > > > > reasons I tried to push Batik 1.7). But recently my second child was > > born > > and > > there is some little chaos in my life with not much time for such tasks. > > I still have SVN Patch yet it is already conflicting at some places with > > new > > code. > > > > What I managed to get was to create an SVG document containing map > > > > (all > > the tiles, either from map or track tiles). It looked significantly > > better than our > > previous drawing mechanism. While it was much less and much simpler > > code. > > Also it scaled nicely. > > > > What the code was missing was: > > (1) drawing station tokens, > > (2) drawing train paths, > > (3) handling scaling and scrolling well, > > (4) support tile selection. > > > > First two would likely require some "hacking" as there is no easy > > way > > > > currently to do it in SVG Document as there is not "specification" of > > tracks > > and stations on an SVG tile. But previous code did it somehow and I > > guess > > that solution could be used with SVG Document as well until (if ever) > > SVG > > tiles will receive better description. (That is a topic interesting on > > its own...) > > The tracks and the token spot locations are also (somewhat cryptically) > defined in Tiles.xml, and these definitions are currently used to draw the > train paths and tokens. > For the time being (or perhaps forever) that can be left as is, drawing > these objects in the top layer of the JLayeredPane that I'm currently > using. However, that would still require achieving correct alignment of > the two layers after zooming. > > > I tries to handle third by using JSVGSrolledPane (or something > > called > > > > similarly) but didn't achieve much. Then I had to interrupt my > > investigations. > > I have also been thinking about JSVGScrolledPane, but I think using that > will only become possible once we manage to do all drawing via JSVG. > > > Fourth should be easy as Batik provides some events to detect this. > > I > > > > expect this could be even easier then current mouse handling. Borders > > around selected or marked tiles could likely be achieved easily with CSS > > in the > > SVG Document. > > Sounds good. > > Erik. > > > --------------------------------------------------------------------------- > --- Simplify data backup and recovery for your virtual environment with > vRanger. Installation's a snap, and flexible recovery options mean your > data is safe, secure and there when you need it. Discover what all the > cheering's about. Get your free trial download today. > http://p.sf.net/sfu/quest-dev2dev2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: brett l. <bre...@gm...> - 2011-08-17 21:53:04
|
Not to pick nits needlessly, but SVG *is* XML. The whole file format is XML. Personally, I'd like to see Rails simply make use of the information contained within the SVG rather than duplicate the exact same information in some other alternative format that's also XML. However, that would require leveraging Batik more extensively, not less. I think I wrote most of the Swing and drawing code. It's crap. ;-) This is because I was learning my way around Swing while writing it. I definitely would like to see it refactored and improved upon. Adam - can you post your patches to show your ideas? It sounds like there's some interest in at least seeing how far you got with your ideas. ---Brett. On Wed, Aug 17, 2011 at 1:48 PM, Adam Badura <ab...@o2...> wrote: > In general I do like thinking that I'm working on it. Yet in reality I > haven't done anything for a long time now. Mostly due to now 2 children > consuming way to much time. ;) (And this requires serious investigations > into Java, SVG and Rails itself thus I have to be rather focused and fresh > to work on it...) > > I would not mind anyone taking over the patch especially that I cannot > promise when I will do it myself. I could serve with advice or reviewing if > that was desired. > > > The patch itself showed only how the map looks like when drawn by providing > SVG document. It was far from usable. (No selection, no proper scrolling, no > stations, ...) > > > I chose generating SVG document (as XML DOM) based on map and current state > (as opposed to drawing through Batik) because: > (1) I think it adds a reasonable layer of abstraction. It is much easier to > write (and then maintain) code that generates XML then code that draws. > (2) I think it is more reusable generally. Such document could be saved and > used outside of Rails. > (3) I simply like XML. And that was part of my investigations in maintining > a better XML+SVG tiles repository for 18xx. > > -----Oryginalna wiadomość----- > From: Stefan Frey > Sent: Wednesday, August 17, 2011 10:43 PM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps) > > Adam & Erik, > going back through the archives of mails, which I did not read carefully > before, I saw this patch. > > What happened to it, it seems that it was not applied to the trunk, but > maybe > it went into a svn branch and was not imported into git? > > I did not look into the display code too much (only a few fixes until now > and > the train paths), however even at that time I was surprised that the > existing > code mainly used standard awt/swing functions instead of the batik svg > functionality. > > The approach of Adam to create a SVG document directly is one way. Another > possibility is to create the SVG document indirectly by replacing the > Graphics2D implementation with the batik provided SVGGraphics2D engine. > > This redirects the Java graphics functions to store the output as SVG > elements > into the SVG document. > > So questions are: Adam are you still working on this? And what was the > reason > for you Erik to not following up this direction (most likely many other to- > dos)? > > I imagine that creating a unified SVG document would make the adding > alternative GUIs much easier than now. > > Stefan > > > > On Monday, June 06, 2011 11:45:57 pm Adam Badura wrote: >> Sorry for the delay but I decided to adapt the patch to current code >> revision and have a look whether it does what I recall it did. Also I >> removed some additional works on symbols which I was doing along (this was >> the reason to start this work) but would be only distracting now. >> >> The code is mostly not documented as it is a working patch. Its not also >> "clean". But it does show that SVG Document isn't that hard. (To scroll or >> zoom use standard Batik components ways: Shift/Ctrl + moves with mouse >> buttons pressed.) >> >> So what do you think? Should I continue my work in this area? >> >> Adam Badura >> >> -----Oryginalna wiadomość----- >> From: Erik Vos >> Sent: Monday, June 06, 2011 2:43 PM >> To: 'Development list for Rails: an 18xx game' >> Subject: Re: [Rails-devel] Background Maps >> >> Adam, >> >> Congratulations with your second child! >> >> I'm certainly interested to have a look at your code, to check if I can >> merge it with my map display code. >> >> Some more comments below. >> >> > -----Oorspronkelijk bericht----- >> > Van: Adam Badura [mailto:ab...@o2...] >> > >> > I was working on moving entire drawing to SVG (and this was one of >> > the >> > >> > reasons I tried to push Batik 1.7). But recently my second child was >> > born >> > and >> > there is some little chaos in my life with not much time for such tasks. >> > I still have SVN Patch yet it is already conflicting at some places with >> > new >> > code. >> > >> > What I managed to get was to create an SVG document containing map >> > >> > (all >> > the tiles, either from map or track tiles). It looked significantly >> > better than our >> > previous drawing mechanism. While it was much less and much simpler >> > code. >> > Also it scaled nicely. >> > >> > What the code was missing was: >> > (1) drawing station tokens, >> > (2) drawing train paths, >> > (3) handling scaling and scrolling well, >> > (4) support tile selection. >> > >> > First two would likely require some "hacking" as there is no easy >> > way >> > >> > currently to do it in SVG Document as there is not "specification" of >> > tracks >> > and stations on an SVG tile. But previous code did it somehow and I >> > guess >> > that solution could be used with SVG Document as well until (if ever) >> > SVG >> > tiles will receive better description. (That is a topic interesting on >> > its own...) >> >> The tracks and the token spot locations are also (somewhat cryptically) >> defined in Tiles.xml, and these definitions are currently used to draw the >> train paths and tokens. >> For the time being (or perhaps forever) that can be left as is, drawing >> these objects in the top layer of the JLayeredPane that I'm currently >> using. However, that would still require achieving correct alignment of >> the two layers after zooming. >> >> > I tries to handle third by using JSVGSrolledPane (or something >> > called >> > >> > similarly) but didn't achieve much. Then I had to interrupt my >> > investigations. >> >> I have also been thinking about JSVGScrolledPane, but I think using that >> will only become possible once we manage to do all drawing via JSVG. >> >> > Fourth should be easy as Batik provides some events to detect this. >> > I >> > >> > expect this could be even easier then current mouse handling. Borders >> > around selected or marked tiles could likely be achieved easily with CSS >> > in the >> > SVG Document. >> >> Sounds good. >> >> Erik. >> >> >> --------------------------------------------------------------------------- >> --- Simplify data backup and recovery for your virtual environment with >> vRanger. Installation's a snap, and flexible recovery options mean your >> data is safe, secure and there when you need it. Discover what all the >> cheering's about. Get your free trial download today. >> http://p.sf.net/sfu/quest-dev2dev2 >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Erik V. <eri...@xs...> - 2011-08-17 22:11:47
|
> Not to pick nits needlessly, but SVG *is* XML. The whole file format is XML. SVG is XML inasmuch Rails is Java. Knowing a language does not necessarily make you understand any content written in that language. |
|
From: Adam B. <ab...@o2...> - 2011-08-17 22:20:11
|
With SVG+XML I meant that (in my opinion) SVG should be used purly for presentation. Tile "description" (like number of stations, track connections between hex edges, stations on that tracks, and so on...) should be stored separately (so not to mix different tile aspects). This also allows to easly use different tile "styles" without need to change code that analyzes runs or finds possible tile lays. As to providing patch with demo of what I am trying to do I will do my best. The patch previously sent by me can no longer be easly applied do to code changes. I will try to produce a new one ASAP. Yet there is not much to look at. Instead of manual drawing I generate SVG document of the map and tiles on it and then set it to Batik Swing component. Batik deals with drawing on its own. -----Oryginalna wiadomość----- From: Erik Vos Sent: Thursday, August 18, 2011 12:12 AM To: 'Development list for Rails: an 18xx game' Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps) > Not to pick nits needlessly, but SVG *is* XML. The whole file format is > XML. SVG is XML inasmuch Rails is Java. Knowing a language does not necessarily make you understand any content written in that language. ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Erik V. <eri...@xs...> - 2011-08-18 09:38:48
|
> -----Original Message----- > From: Adam Badura [mailto:ab...@o2...] > Sent: Thursday, August 18, 2011 12:20 AM > To: 'Development list for Rails: an 18xx game' > Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps) > > With SVG+XML I meant that (in my opinion) SVG should be used purly for > presentation. Tile "description" (like number of stations, track connections > between hex edges, stations on that tracks, and so on...) should be stored > separately (so not to mix different tile aspects). This also allows to easly use > different tile "styles" without need to change code that analyzes runs or > finds possible tile lays. I fully agree with that. Several games have hexes and tiles where the picture does not reflect the full connectivity function of that hex/tile. Examples: - PRR and Reading bases in the 1830 Coalfields and Reading variants, - Most off-map hexes, and specifically the 1856 Goderich and 18EU Hamburg: there is an undisplayed city on these hexes, that in the two cases mentioned can even be run through. - the sticky version of the brown plain track tiles in some games, like 18EU. In these cases the connectivity specification (in Tiles.xml) and the SVG picture are different, so the latter is unusable to base route calculations upon. Erik. |
|
From: Adam B. <ab...@o2...> - 2011-08-17 23:05:44
Attachments:
Rails SVG.patch
|
On attachement patch for SVG document to be applied at current revision. With code modified that way load an existing game and enjoy the board (now I only checked 18AL, but others should work to). Batik provides internal manipulators. While holding Ctrl use left and right mouse buttons to rotate or zoom for example (see how on large zooms the tiles still fit well). -----Oryginalna wiadomość----- From: brett lentz Sent: Wednesday, August 17, 2011 11:52 PM To: Development list for Rails: an 18xx game Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps) Not to pick nits needlessly, but SVG *is* XML. The whole file format is XML. Personally, I'd like to see Rails simply make use of the information contained within the SVG rather than duplicate the exact same information in some other alternative format that's also XML. However, that would require leveraging Batik more extensively, not less. I think I wrote most of the Swing and drawing code. It's crap. ;-) This is because I was learning my way around Swing while writing it. I definitely would like to see it refactored and improved upon. Adam - can you post your patches to show your ideas? It sounds like there's some interest in at least seeing how far you got with your ideas. ---Brett. On Wed, Aug 17, 2011 at 1:48 PM, Adam Badura <ab...@o2...> wrote: > In general I do like thinking that I'm working on it. Yet in reality I > haven't done anything for a long time now. Mostly due to now 2 children > consuming way to much time. ;) (And this requires serious investigations > into Java, SVG and Rails itself thus I have to be rather focused and fresh > to work on it...) > > I would not mind anyone taking over the patch especially that I cannot > promise when I will do it myself. I could serve with advice or reviewing > if > that was desired. > > > The patch itself showed only how the map looks like when drawn by > providing > SVG document. It was far from usable. (No selection, no proper scrolling, > no > stations, ...) > > > I chose generating SVG document (as XML DOM) based on map and current > state > (as opposed to drawing through Batik) because: > (1) I think it adds a reasonable layer of abstraction. It is much easier > to > write (and then maintain) code that generates XML then code that draws. > (2) I think it is more reusable generally. Such document could be saved > and > used outside of Rails. > (3) I simply like XML. And that was part of my investigations in > maintining > a better XML+SVG tiles repository for 18xx. > > -----Oryginalna wiadomość----- > From: Stefan Frey > Sent: Wednesday, August 17, 2011 10:43 PM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps) > > Adam & Erik, > going back through the archives of mails, which I did not read carefully > before, I saw this patch. > > What happened to it, it seems that it was not applied to the trunk, but > maybe > it went into a svn branch and was not imported into git? > > I did not look into the display code too much (only a few fixes until now > and > the train paths), however even at that time I was surprised that the > existing > code mainly used standard awt/swing functions instead of the batik svg > functionality. > > The approach of Adam to create a SVG document directly is one way. Another > possibility is to create the SVG document indirectly by replacing the > Graphics2D implementation with the batik provided SVGGraphics2D engine. > > This redirects the Java graphics functions to store the output as SVG > elements > into the SVG document. > > So questions are: Adam are you still working on this? And what was the > reason > for you Erik to not following up this direction (most likely many other > to- > dos)? > > I imagine that creating a unified SVG document would make the adding > alternative GUIs much easier than now. > > Stefan > > > > On Monday, June 06, 2011 11:45:57 pm Adam Badura wrote: >> Sorry for the delay but I decided to adapt the patch to current code >> revision and have a look whether it does what I recall it did. Also I >> removed some additional works on symbols which I was doing along (this >> was >> the reason to start this work) but would be only distracting now. >> >> The code is mostly not documented as it is a working patch. Its not also >> "clean". But it does show that SVG Document isn't that hard. (To scroll >> or >> zoom use standard Batik components ways: Shift/Ctrl + moves with mouse >> buttons pressed.) >> >> So what do you think? Should I continue my work in this area? >> >> Adam Badura >> >> -----Oryginalna wiadomość----- >> From: Erik Vos >> Sent: Monday, June 06, 2011 2:43 PM >> To: 'Development list for Rails: an 18xx game' >> Subject: Re: [Rails-devel] Background Maps >> >> Adam, >> >> Congratulations with your second child! >> >> I'm certainly interested to have a look at your code, to check if I can >> merge it with my map display code. >> >> Some more comments below. >> >> > -----Oorspronkelijk bericht----- >> > Van: Adam Badura [mailto:ab...@o2...] >> > >> > I was working on moving entire drawing to SVG (and this was one of >> > the >> > >> > reasons I tried to push Batik 1.7). But recently my second child was >> > born >> > and >> > there is some little chaos in my life with not much time for such >> > tasks. >> > I still have SVN Patch yet it is already conflicting at some places >> > with >> > new >> > code. >> > >> > What I managed to get was to create an SVG document containing map >> > >> > (all >> > the tiles, either from map or track tiles). It looked significantly >> > better than our >> > previous drawing mechanism. While it was much less and much simpler >> > code. >> > Also it scaled nicely. >> > >> > What the code was missing was: >> > (1) drawing station tokens, >> > (2) drawing train paths, >> > (3) handling scaling and scrolling well, >> > (4) support tile selection. >> > >> > First two would likely require some "hacking" as there is no easy >> > way >> > >> > currently to do it in SVG Document as there is not "specification" of >> > tracks >> > and stations on an SVG tile. But previous code did it somehow and I >> > guess >> > that solution could be used with SVG Document as well until (if ever) >> > SVG >> > tiles will receive better description. (That is a topic interesting on >> > its own...) >> >> The tracks and the token spot locations are also (somewhat cryptically) >> defined in Tiles.xml, and these definitions are currently used to draw >> the >> train paths and tokens. >> For the time being (or perhaps forever) that can be left as is, drawing >> these objects in the top layer of the JLayeredPane that I'm currently >> using. However, that would still require achieving correct alignment of >> the two layers after zooming. >> >> > I tries to handle third by using JSVGSrolledPane (or something >> > called >> > >> > similarly) but didn't achieve much. Then I had to interrupt my >> > investigations. >> >> I have also been thinking about JSVGScrolledPane, but I think using that >> will only become possible once we manage to do all drawing via JSVG. >> >> > Fourth should be easy as Batik provides some events to detect this. >> > I >> > >> > expect this could be even easier then current mouse handling. Borders >> > around selected or marked tiles could likely be achieved easily with >> > CSS >> > in the >> > SVG Document. >> >> Sounds good. >> >> Erik. >> >> >> --------------------------------------------------------------------------- >> --- Simplify data backup and recovery for your virtual environment with >> vRanger. Installation's a snap, and flexible recovery options mean your >> data is safe, secure and there when you need it. Discover what all the >> cheering's about. Get your free trial download today. >> http://p.sf.net/sfu/quest-dev2dev2 >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Erik V. <eri...@xs...> - 2011-08-18 09:43:00
|
There is another SVG related open issue with the 18EU SVG map that has been added a while ago. It looks nice, but on zooming in and out repeatedly, the scales of the map and the laid tiles start running out of sync. I was not able to fix that. Erik. > -----Original Message----- > From: Adam Badura [mailto:ab...@o2...] > Sent: Thursday, August 18, 2011 1:06 AM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps) > > On attachement patch for SVG document to be applied at current revision. > With code modified that way load an existing game and enjoy the board > (now I only checked 18AL, but others should work to). > > Batik provides internal manipulators. While holding Ctrl use left and right > mouse buttons to rotate or zoom for example (see how on large zooms the > tiles still fit well). > > -----Oryginalna wiadomość----- > From: brett lentz > Sent: Wednesday, August 17, 2011 11:52 PM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] batik and svg documents (was: Background Maps) > > Not to pick nits needlessly, but SVG *is* XML. The whole file format is XML. > > Personally, I'd like to see Rails simply make use of the information contained > within the SVG rather than duplicate the exact same information in some > other alternative format that's also XML. However, that would require > leveraging Batik more extensively, not less. > > I think I wrote most of the Swing and drawing code. It's crap. ;-) This is > because I was learning my way around Swing while writing it. I definitely > would like to see it refactored and improved upon. > > Adam - can you post your patches to show your ideas? It sounds like there's > some interest in at least seeing how far you got with your ideas. > > ---Brett. > > > > On Wed, Aug 17, 2011 at 1:48 PM, Adam Badura <ab...@o2...> wrote: > > In general I do like thinking that I'm working on it. Yet in reality I > > haven't done anything for a long time now. Mostly due to now 2 > > children consuming way to much time. ;) (And this requires serious > > investigations into Java, SVG and Rails itself thus I have to be > > rather focused and fresh to work on it...) > > > > I would not mind anyone taking over the patch especially that I cannot > > promise when I will do it myself. I could serve with advice or > > reviewing if that was desired. > > > > > > The patch itself showed only how the map looks like when drawn by > > providing SVG document. It was far from usable. (No selection, no > > proper scrolling, no stations, ...) > > > > > > I chose generating SVG document (as XML DOM) based on map and > current > > state (as opposed to drawing through Batik) because: > > (1) I think it adds a reasonable layer of abstraction. It is much > > easier to write (and then maintain) code that generates XML then code > > that draws. > > (2) I think it is more reusable generally. Such document could be > > saved and used outside of Rails. > > (3) I simply like XML. And that was part of my investigations in > > maintining a better XML+SVG tiles repository for 18xx. > > > > -----Oryginalna wiadomość----- > > From: Stefan Frey > > Sent: Wednesday, August 17, 2011 10:43 PM > > To: Development list for Rails: an 18xx game > > Subject: Re: [Rails-devel] batik and svg documents (was: Background > > Maps) > > > > Adam & Erik, > > going back through the archives of mails, which I did not read > > carefully before, I saw this patch. > > > > What happened to it, it seems that it was not applied to the trunk, > > but maybe it went into a svn branch and was not imported into git? > > > > I did not look into the display code too much (only a few fixes until > > now and the train paths), however even at that time I was surprised > > that the existing code mainly used standard awt/swing functions > > instead of the batik svg functionality. > > > > The approach of Adam to create a SVG document directly is one way. > > Another possibility is to create the SVG document indirectly by > > replacing the Graphics2D implementation with the batik provided > SVGGraphics2D engine. > > > > This redirects the Java graphics functions to store the output as SVG > > elements into the SVG document. > > > > So questions are: Adam are you still working on this? And what was the > > reason for you Erik to not following up this direction (most likely > > many other > > to- > > dos)? > > > > I imagine that creating a unified SVG document would make the adding > > alternative GUIs much easier than now. > > > > Stefan > > > > > > > > On Monday, June 06, 2011 11:45:57 pm Adam Badura wrote: > >> Sorry for the delay but I decided to adapt the patch to current code > >> revision and have a look whether it does what I recall it did. Also I > >> removed some additional works on symbols which I was doing along > >> (this was the reason to start this work) but would be only > >> distracting now. > >> > >> The code is mostly not documented as it is a working patch. Its not > >> also "clean". But it does show that SVG Document isn't that hard. (To > >> scroll or zoom use standard Batik components ways: Shift/Ctrl + moves > >> with mouse buttons pressed.) > >> > >> So what do you think? Should I continue my work in this area? > >> > >> Adam Badura > >> > >> -----Oryginalna wiadomość----- > >> From: Erik Vos > >> Sent: Monday, June 06, 2011 2:43 PM > >> To: 'Development list for Rails: an 18xx game' > >> Subject: Re: [Rails-devel] Background Maps > >> > >> Adam, > >> > >> Congratulations with your second child! > >> > >> I'm certainly interested to have a look at your code, to check if I > >> can merge it with my map display code. > >> > >> Some more comments below. > >> > >> > -----Oorspronkelijk bericht----- > >> > Van: Adam Badura [mailto:ab...@o2...] > >> > > >> > I was working on moving entire drawing to SVG (and this was one of > >> > the > >> > > >> > reasons I tried to push Batik 1.7). But recently my second child > >> > was born and there is some little chaos in my life with not much > >> > time for such tasks. > >> > I still have SVN Patch yet it is already conflicting at some places > >> > with new code. > >> > > >> > What I managed to get was to create an SVG document containing > >> > map > >> > > >> > (all > >> > the tiles, either from map or track tiles). It looked significantly > >> > better than our previous drawing mechanism. While it was much less > >> > and much simpler code. > >> > Also it scaled nicely. > >> > > >> > What the code was missing was: > >> > (1) drawing station tokens, > >> > (2) drawing train paths, > >> > (3) handling scaling and scrolling well, > >> > (4) support tile selection. > >> > > >> > First two would likely require some "hacking" as there is no > >> > easy way > >> > > >> > currently to do it in SVG Document as there is not "specification" > >> > of tracks and stations on an SVG tile. But previous code did it > >> > somehow and I guess that solution could be used with SVG Document > >> > as well until (if ever) SVG tiles will receive better description. > >> > (That is a topic interesting on its own...) > >> > >> The tracks and the token spot locations are also (somewhat > >> cryptically) defined in Tiles.xml, and these definitions are > >> currently used to draw the train paths and tokens. > >> For the time being (or perhaps forever) that can be left as is, > >> drawing these objects in the top layer of the JLayeredPane that I'm > >> currently using. However, that would still require achieving correct > >> alignment of the two layers after zooming. > >> > >> > I tries to handle third by using JSVGSrolledPane (or something > >> > called > >> > > >> > similarly) but didn't achieve much. Then I had to interrupt my > >> > investigations. > >> > >> I have also been thinking about JSVGScrolledPane, but I think using > >> that will only become possible once we manage to do all drawing via JSVG. > >> > >> > Fourth should be easy as Batik provides some events to detect this. > >> > I > >> > > >> > expect this could be even easier then current mouse handling. > >> > Borders around selected or marked tiles could likely be achieved > >> > easily with CSS in the SVG Document. > >> > >> Sounds good. > >> > >> Erik. > >> > >> > >> --------------------------------------------------------------------- > >> ------ > >> --- Simplify data backup and recovery for your virtual environment > >> with vRanger. Installation's a snap, and flexible recovery options > >> mean your data is safe, secure and there when you need it. Discover > >> what all the cheering's about. Get your free trial download today. > >> http://p.sf.net/sfu/quest-dev2dev2 > >> _______________________________________________ > >> Rails-devel mailing list > >> Rai...@li... > >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > ---------------------------------------------------------------------- > > -------- Get a FREE DOWNLOAD! and learn more about uberSVN rich > > system, user administration capabilities and model configuration. Take > > the hassle out of deploying and managing Subversion and the tools > > developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > ---------------------------------------------------------------------- > > -------- Get a FREE DOWNLOAD! and learn more about uberSVN rich > > system, user administration capabilities and model configuration. Take > > the hassle out of deploying and managing Subversion and the tools > > developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user > administration capabilities and model configuration. Take the hassle out of > deploying and managing Subversion and the tools developers use with it. > http://p.sf.net/sfu/wandisco-d2d-2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Erik V. <eri...@xs...> - 2011-08-17 21:35:26
|
> And what was the > reason for you Erik to not following up this direction (most likely many other > to- dos)? I have never been seriously involved in any graphics programming. I just understand Swing to some extent, but please don't ask any deep questions. Nevertheless Adam had succeeded in raising some interest with me about SVG programming, so I tried to find some usable introductory documentation on how to use Batik. But I couldn't find anything. So I quit. Erik. |
|
From: Erik V. <eri...@xs...> - 2011-06-07 11:56:51
|
I fully agree that this is the way to go for the future. In the meantime, I will commit my and some of Bill's work on the map image integration (imperfect as it currently is), trusting that you will ultimately also be able to integrate SVG map images into your work. Erik > -----Oorspronkelijk bericht----- > Van: Adam Badura [mailto:ab...@o2...] > Verzonden: dinsdag 7 juni 2011 7:38 > Aan: Development list for Rails: an 18xx game > Onderwerp: Re: [Rails-devel] Background Maps > > OK. Great. Then I shell continue this work. Yet I cannot promise when it will > be done. But I will try to report on progress every now and then. > > Adam Badura > > -----Oryginalna wiadomość----- > From: brett lentz > Sent: Tuesday, June 07, 2011 6:31 AM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Background Maps > > I think this is an excellent direction to continue working on. > > The patch looks like it consolidates a bunch of code into a couple of classes, > which looks good on first glance. > > I'd definitely like to see the finished patch once you're ready for it to be > merged into the codebase. > > ---Brett. > > > > On Mon, Jun 6, 2011 at 2:45 PM, Adam Badura <ab...@o2...> wrote: > > Sorry for the delay but I decided to adapt the patch to current code > > revision and have a look whether it does what I recall it did. Also I > > removed some additional works on symbols which I was doing along (this > > was the reason to start this work) but would be only distracting now. > > > > The code is mostly not documented as it is a working patch. Its not > > also "clean". But it does show that SVG Document isn't that hard. (To > > scroll or zoom use standard Batik components ways: Shift/Ctrl + moves > > with mouse buttons pressed.) > > > > So what do you think? Should I continue my work in this area? > > > > Adam Badura > > > > -----Oryginalna wiadomość----- From: Erik Vos > > Sent: Monday, June 06, 2011 2:43 PM > > To: 'Development list for Rails: an 18xx game' > > Subject: Re: [Rails-devel] Background Maps > > > > Adam, > > > > Congratulations with your second child! > > > > I'm certainly interested to have a look at your code, to check if I > > can merge it with my map display code. > > > > Some more comments below. > > > >> -----Oorspronkelijk bericht----- > >> Van: Adam Badura [mailto:ab...@o2...] > >> > >> I was working on moving entire drawing to SVG (and this was one of > >> the reasons I tried to push Batik 1.7). But recently my second child > >> was born and there is some little chaos in my life with not much time > >> for such tasks. > >> I still have SVN Patch yet it is already conflicting at some places > >> with new code. > >> > >> What I managed to get was to create an SVG document containing map > >> (all the tiles, either from map or track tiles). It looked > >> significantly better than our previous drawing mechanism. While it > >> was much less and much simpler code. > >> Also it scaled nicely. > >> > >> What the code was missing was: > >> (1) drawing station tokens, > >> (2) drawing train paths, > >> (3) handling scaling and scrolling well, > >> (4) support tile selection. > >> > >> First two would likely require some "hacking" as there is no easy > >> way currently to do it in SVG Document as there is not > >> "specification" of tracks and stations on an SVG tile. But previous > >> code did it somehow and I guess that solution could be used with SVG > >> Document as well until (if ever) SVG tiles will receive better > >> description. (That is a topic interesting on its > >> own...) > > > > The tracks and the token spot locations are also (somewhat > > cryptically) defined in Tiles.xml, and these definitions are currently > > used to draw the train paths and tokens. > > For the time being (or perhaps forever) that can be left as is, > > drawing these objects in the top layer of the JLayeredPane that I'm > > currently using. > > However, that would still require achieving correct alignment of the > > two layers after zooming. > > > >> I tries to handle third by using JSVGSrolledPane (or something > >> called > >> similarly) but didn't achieve much. Then I had to interrupt my > >> investigations. > > > > I have also been thinking about JSVGScrolledPane, but I think using > > that will only become possible once we manage to do all drawing via JSVG. > > > >> Fourth should be easy as Batik provides some events to detect > >> this. I expect this could be even easier then current mouse handling. > >> Borders around selected or marked tiles could likely be achieved > >> easily with CSS in the SVG Document. > > > > Sounds good. > > > > Erik. > > > > > > ---------------------------------------------------------------------- > > -------- Simplify data backup and recovery for your virtual > > environment with vRanger. > > Installation's a snap, and flexible recovery options mean your data is > > safe, secure and there when you need it. Discover what all the > > cheering's about. > > Get your free trial download today. > > http://p.sf.net/sfu/quest-dev2dev2 > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > ---------------------------------------------------------------------- > > -------- EditLive Enterprise is the world's most technically advanced > > content authoring tool. Experience the power of Track Changes, Inline > > Image Editing and ensure content is compliant with Accessibility > > Checking. > > http://p.sf.net/sfu/ephox-dev2dev > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image Editing > and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image Editing > and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Adam B. <ab...@o2...> - 2011-06-07 12:25:16
|
OK. So once you add that background I will add it to my code to and
share the results.
Note thou that if the background will be a raster image then scaling
will no longer look that well. On the other hand I expect backgrounds to be
rather simple so maybe the will not suffer as much due to scaling.
Adam Badura
-----Oryginalna wiadomość-----
From: Erik Vos
Sent: Tuesday, June 07, 2011 1:56 PM
To: 'Development list for Rails: an 18xx game'
Subject: Re: [Rails-devel] Background Maps
I fully agree that this is the way to go for the future.
In the meantime, I will commit my and some of Bill's work on the map image
integration (imperfect as it currently is), trusting that you will
ultimately also be able to integrate SVG map images into your work.
Erik
> -----Oorspronkelijk bericht-----
> Van: Adam Badura [mailto:ab...@o2...]
> Verzonden: dinsdag 7 juni 2011 7:38
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] Background Maps
>
> OK. Great. Then I shell continue this work. Yet I cannot promise when it
> will
> be done. But I will try to report on progress every now and then.
>
> Adam Badura
>
> -----Oryginalna wiadomość-----
> From: brett lentz
> Sent: Tuesday, June 07, 2011 6:31 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Background Maps
>
> I think this is an excellent direction to continue working on.
>
> The patch looks like it consolidates a bunch of code into a couple of
> classes,
> which looks good on first glance.
>
> I'd definitely like to see the finished patch once you're ready for it to
> be
> merged into the codebase.
>
> ---Brett.
>
>
>
> On Mon, Jun 6, 2011 at 2:45 PM, Adam Badura <ab...@o2...> wrote:
> > Sorry for the delay but I decided to adapt the patch to current code
> > revision and have a look whether it does what I recall it did. Also I
> > removed some additional works on symbols which I was doing along (this
> > was the reason to start this work) but would be only distracting now.
> >
> > The code is mostly not documented as it is a working patch. Its not
> > also "clean". But it does show that SVG Document isn't that hard. (To
> > scroll or zoom use standard Batik components ways: Shift/Ctrl + moves
> > with mouse buttons pressed.)
> >
> > So what do you think? Should I continue my work in this area?
> >
> > Adam Badura
> >
> > -----Oryginalna wiadomość----- From: Erik Vos
> > Sent: Monday, June 06, 2011 2:43 PM
> > To: 'Development list for Rails: an 18xx game'
> > Subject: Re: [Rails-devel] Background Maps
> >
> > Adam,
> >
> > Congratulations with your second child!
> >
> > I'm certainly interested to have a look at your code, to check if I
> > can merge it with my map display code.
> >
> > Some more comments below.
> >
> >> -----Oorspronkelijk bericht-----
> >> Van: Adam Badura [mailto:ab...@o2...]
> >>
> >> I was working on moving entire drawing to SVG (and this was one of
> >> the reasons I tried to push Batik 1.7). But recently my second child
> >> was born and there is some little chaos in my life with not much time
> >> for such tasks.
> >> I still have SVN Patch yet it is already conflicting at some places
> >> with new code.
> >>
> >> What I managed to get was to create an SVG document containing map
> >> (all the tiles, either from map or track tiles). It looked
> >> significantly better than our previous drawing mechanism. While it
> >> was much less and much simpler code.
> >> Also it scaled nicely.
> >>
> >> What the code was missing was:
> >> (1) drawing station tokens,
> >> (2) drawing train paths,
> >> (3) handling scaling and scrolling well,
> >> (4) support tile selection.
> >>
> >> First two would likely require some "hacking" as there is no easy
> >> way currently to do it in SVG Document as there is not
> >> "specification" of tracks and stations on an SVG tile. But previous
> >> code did it somehow and I guess that solution could be used with SVG
> >> Document as well until (if ever) SVG tiles will receive better
> >> description. (That is a topic interesting on its
> >> own...)
> >
> > The tracks and the token spot locations are also (somewhat
> > cryptically) defined in Tiles.xml, and these definitions are currently
> > used to draw the train paths and tokens.
> > For the time being (or perhaps forever) that can be left as is,
> > drawing these objects in the top layer of the JLayeredPane that I'm
> > currently using.
> > However, that would still require achieving correct alignment of the
> > two layers after zooming.
> >
> >> I tries to handle third by using JSVGSrolledPane (or something
> >> called
> >> similarly) but didn't achieve much. Then I had to interrupt my
> >> investigations.
> >
> > I have also been thinking about JSVGScrolledPane, but I think using
> > that will only become possible once we manage to do all drawing via
> > JSVG.
> >
> >> Fourth should be easy as Batik provides some events to detect
> >> this. I expect this could be even easier then current mouse handling.
> >> Borders around selected or marked tiles could likely be achieved
> >> easily with CSS in the SVG Document.
> >
> > Sounds good.
> >
> > Erik.
> >
> >
> > ----------------------------------------------------------------------
> > -------- Simplify data backup and recovery for your virtual
> > environment with vRanger.
> > Installation's a snap, and flexible recovery options mean your data is
> > safe, secure and there when you need it. Discover what all the
> > cheering's about.
> > Get your free trial download today.
> > http://p.sf.net/sfu/quest-dev2dev2
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > ----------------------------------------------------------------------
> > -------- EditLive Enterprise is the world's most technically advanced
> > content authoring tool. Experience the power of Track Changes, Inline
> > Image Editing and ensure content is compliant with Accessibility
> > Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing
> and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing
> and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: Erik V. <eri...@xs...> - 2011-06-07 16:04:44
|
OK, I have committed the current code, which includes an SVG background map for 18EU (contributed by Bill Rosgen, IIRC). To enable seeing the map, one entry needs be added to your custom my.properties file (I haven't tried to update the configuration menu yet): - map.image.display=yes (default no, in which case everything works as before). I have included Bill Rosgen's patch to highlight selected hexes somewhat differently. Currently, it only affects display when the map is used. The original highlighting looks ugly in this case. Please don't Zoom in serious play when the map image is used: it does not yet work as it should. When I try, the tiles rescale correctly, and so does the map image, but the latter soon gets out of sync. It's not clear to me how JSVGCanvas rescaling+resizing should be programmed the right way. A scaling affine transform works fine, which is what I used initially. But it not change the canvas size, so part of the map becomes invisible on zooming in. Only setting the canvas bounds (setBounds()) initially does the whole job, and this is what I'm currently using. But on repeated zooming actions, it seems to rescale the map image only every other time. Doing both (scale and setBounds) upscales the map twice. It may be a matter of timing, and perhaps some listener should be invoked, but I cannot find any pointer on what exactly would be needed. Erik. > -----Oorspronkelijk bericht----- > Van: Erik Vos [mailto:eri...@xs...] > Verzonden: dinsdag 7 juni 2011 13:57 > Aan: 'Development list for Rails: an 18xx game' > Onderwerp: Re: [Rails-devel] Background Maps > > I fully agree that this is the way to go for the future. > In the meantime, I will commit my and some of Bill's work on the map image > integration (imperfect as it currently is), trusting that you will ultimately also > be able to integrate SVG map images into your work. > > Erik > > > -----Oorspronkelijk bericht----- > > Van: Adam Badura [mailto:ab...@o2...] > > Verzonden: dinsdag 7 juni 2011 7:38 > > Aan: Development list for Rails: an 18xx game > > Onderwerp: Re: [Rails-devel] Background Maps > > > > OK. Great. Then I shell continue this work. Yet I cannot promise when > > it will be done. But I will try to report on progress every now and then. > > > > Adam Badura > > > > -----Oryginalna wiadomość----- > > From: brett lentz > > Sent: Tuesday, June 07, 2011 6:31 AM > > To: Development list for Rails: an 18xx game > > Subject: Re: [Rails-devel] Background Maps > > > > I think this is an excellent direction to continue working on. > > > > The patch looks like it consolidates a bunch of code into a couple of > > classes, which looks good on first glance. > > > > I'd definitely like to see the finished patch once you're ready for it > > to be merged into the codebase. > > > > ---Brett. > > > > > > > > On Mon, Jun 6, 2011 at 2:45 PM, Adam Badura <ab...@o2...> wrote: > > > Sorry for the delay but I decided to adapt the patch to current code > > > revision and have a look whether it does what I recall it did. Also > > > I removed some additional works on symbols which I was doing along > > > (this was the reason to start this work) but would be only distracting now. > > > > > > The code is mostly not documented as it is a working patch. Its not > > > also "clean". But it does show that SVG Document isn't that hard. > > > (To scroll or zoom use standard Batik components ways: Shift/Ctrl + > > > moves with mouse buttons pressed.) > > > > > > So what do you think? Should I continue my work in this area? > > > > > > Adam Badura > > > > > > -----Oryginalna wiadomość----- From: Erik Vos > > > Sent: Monday, June 06, 2011 2:43 PM > > > To: 'Development list for Rails: an 18xx game' > > > Subject: Re: [Rails-devel] Background Maps > > > > > > Adam, > > > > > > Congratulations with your second child! > > > > > > I'm certainly interested to have a look at your code, to check if I > > > can merge it with my map display code. > > > > > > Some more comments below. > > > > > >> -----Oorspronkelijk bericht----- > > >> Van: Adam Badura [mailto:ab...@o2...] > > >> > > >> I was working on moving entire drawing to SVG (and this was one > > >> of the reasons I tried to push Batik 1.7). But recently my second > > >> child was born and there is some little chaos in my life with not > > >> much time for such tasks. > > >> I still have SVN Patch yet it is already conflicting at some places > > >> with new code. > > >> > > >> What I managed to get was to create an SVG document containing > > >> map (all the tiles, either from map or track tiles). It looked > > >> significantly better than our previous drawing mechanism. While it > > >> was much less and much simpler code. > > >> Also it scaled nicely. > > >> > > >> What the code was missing was: > > >> (1) drawing station tokens, > > >> (2) drawing train paths, > > >> (3) handling scaling and scrolling well, > > >> (4) support tile selection. > > >> > > >> First two would likely require some "hacking" as there is no > > >> easy way currently to do it in SVG Document as there is not > > >> "specification" of tracks and stations on an SVG tile. But previous > > >> code did it somehow and I guess that solution could be used with > > >> SVG Document as well until (if ever) SVG tiles will receive better > > >> description. (That is a topic interesting on its > > >> own...) > > > > > > The tracks and the token spot locations are also (somewhat > > > cryptically) defined in Tiles.xml, and these definitions are > > > currently used to draw the train paths and tokens. > > > For the time being (or perhaps forever) that can be left as is, > > > drawing these objects in the top layer of the JLayeredPane that I'm > > > currently using. > > > However, that would still require achieving correct alignment of the > > > two layers after zooming. > > > > > >> I tries to handle third by using JSVGSrolledPane (or something > > >> called > > >> similarly) but didn't achieve much. Then I had to interrupt my > > >> investigations. > > > > > > I have also been thinking about JSVGScrolledPane, but I think using > > > that will only become possible once we manage to do all drawing via > JSVG. > > > > > >> Fourth should be easy as Batik provides some events to detect > > >> this. I expect this could be even easier then current mouse handling. > > >> Borders around selected or marked tiles could likely be achieved > > >> easily with CSS in the SVG Document. > > > > > > Sounds good. > > > > > > Erik. > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > -------- Simplify data backup and recovery for your virtual > > > environment with vRanger. > > > Installation's a snap, and flexible recovery options mean your data > > > is safe, secure and there when you need it. Discover what all the > > > cheering's about. > > > Get your free trial download today. > > > http://p.sf.net/sfu/quest-dev2dev2 > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > -------------------------------------------------------------------- > > > -- > > > -------- EditLive Enterprise is the world's most technically > > > advanced content authoring tool. Experience the power of Track > > > Changes, Inline Image Editing and ensure content is compliant with > > > Accessibility Checking. > > > http://p.sf.net/sfu/ephox-dev2dev > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > ---------------------------------------------------------------------- > > -------- EditLive Enterprise is the world's most technically advanced > > content authoring tool. Experience the power of Track Changes, Inline > > Image Editing and ensure content is compliant with Accessibility > > Checking. > > http://p.sf.net/sfu/ephox-dev2dev > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > ---------------------------------------------------------------------- > > -------- EditLive Enterprise is the world's most technically advanced > > content authoring tool. Experience the power of Track Changes, Inline > > Image Editing and ensure content is compliant with Accessibility > > Checking. > > http://p.sf.net/sfu/ephox-dev2dev > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image Editing > and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Bill R. <ro...@gm...> - 2011-06-07 16:32:26
|
On 2011-06-08, at 0:04 , Erik Vos wrote: > OK, I have committed the current code, which includes an SVG background map for 18EU (contributed by Bill Rosgen, IIRC). To be fair: it's not my map. I simply cut out some pieces of the map released by Deep Thought. Bill |
|
From: Erik V. <eri...@xs...> - 2011-06-07 17:26:54
|
I didn't say that you created it... For sure, DTG will be mentioned in the credits. Erik. > -----Oorspronkelijk bericht----- > Van: Bill Rosgen [mailto:ro...@gm...] > Verzonden: dinsdag 7 juni 2011 18:32 > Aan: Development list for Rails: an 18xx game > Onderwerp: Re: [Rails-devel] Background Maps > > > On 2011-06-08, at 0:04 , Erik Vos wrote: > > > OK, I have committed the current code, which includes an SVG background > map for 18EU (contributed by Bill Rosgen, IIRC). > > To be fair: it's not my map. I simply cut out some pieces of the map released > by Deep Thought. > > Bill > > > > ---------------------------------------------------------------------------- -- > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image Editing > and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: John A. T. <ja...@ja...> - 2011-06-07 18:46:33
|
On Tue, Jun 7, 2011 at 1:26 PM, Erik Vos <eri...@xs...> wrote: > I didn't say that you created it... > For sure, DTG will be mentioned in the credits. > I don't care -- however, it would probably be easier next time to ask me for it in SVG form rather than reverse-engineering it from PDFs :). -- John A. Tamplin |
|
From: Adam B. <ab...@o2...> - 2011-06-07 18:54:50
|
So could you provide the SVG background? My post manager shows an attachment mark at your post but it does not provide the attachment...
Adam Badura
From: John A. Tamplin
Sent: Tuesday, June 07, 2011 8:46 PM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Background Maps
On Tue, Jun 7, 2011 at 1:26 PM, Erik Vos <eri...@xs...> wrote:
I didn't say that you created it...
For sure, DTG will be mentioned in the credits.
I don't care -- however, it would probably be easier next time to ask me for it in SVG form rather than reverse-engineering it from PDFs :).
--
John A. Tamplin
--------------------------------------------------------------------------------
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
--------------------------------------------------------------------------------
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: Stefan F. <ste...@we...> - 2011-06-11 06:05:44
|
The background map can now be activated in the configuration menu in the Map/Report section. The required changes are summarized below for future reference. I will move this example to the wiki with some more instructions on the configuration menu. Stefan To be supported in the configuration menu a new entry requires the following: A) An XML definition in data => Properties.xml B) A default value in data.profiles => default.profile C) A menu text in LocalisedText.properties Prefix is Config.label. followed by the property name For this example here: A) <Property name="map.image.display" type="BOOLEAN" /> in section UI B) map.image.display=no C) Config.label.map.display=Display background map On Tuesday, June 07, 2011 06:04:37 pm Erik Vos wrote: > OK, I have committed the current code, which includes an SVG background > map for 18EU (contributed by Bill Rosgen, IIRC). > > To enable seeing the map, one entry needs be added to your custom > my.properties file (I haven't tried to update the configuration menu yet): > - map.image.display=yes (default no, in which case everything works as > before). > > I have included Bill Rosgen's patch to highlight selected hexes somewhat > differently. Currently, it only affects display when the map is used. > The original highlighting looks ugly in this case. > > Please don't Zoom in serious play when the map image is used: it does not > yet work as it should. When I try, the tiles rescale correctly, and so > does the map image, but the latter soon gets out of sync. > > It's not clear to me how JSVGCanvas rescaling+resizing should be programmed > the right way. A scaling affine transform works fine, which is what I used > initially. But it not change the canvas size, so part of the map becomes > invisible on zooming in. Only setting the canvas bounds (setBounds()) > initially does the whole job, and this is what I'm currently using. But > on repeated zooming actions, it seems to rescale the map image only every > other time. Doing both (scale and setBounds) upscales the map twice. > > It may be a matter of timing, and perhaps some listener should be invoked, > but I cannot find any pointer on what exactly would be needed. > > Erik. > > > -----Oorspronkelijk bericht----- > > Van: Erik Vos [mailto:eri...@xs...] > > Verzonden: dinsdag 7 juni 2011 13:57 > > Aan: 'Development list for Rails: an 18xx game' > > Onderwerp: Re: [Rails-devel] Background Maps > > > > I fully agree that this is the way to go for the future. > > In the meantime, I will commit my and some of Bill's work on the map > > image integration (imperfect as it currently is), trusting that you will > > ultimately also be able to integrate SVG map images into your work. > > > > Erik > > > > > -----Oorspronkelijk bericht----- > > > Van: Adam Badura [mailto:ab...@o2...] > > > Verzonden: dinsdag 7 juni 2011 7:38 > > > Aan: Development list for Rails: an 18xx game > > > Onderwerp: Re: [Rails-devel] Background Maps > > > > > > OK. Great. Then I shell continue this work. Yet I cannot promise when > > > it will be done. But I will try to report on progress every now and > > > then. > > > > > > Adam Badura > > > > > > -----Oryginalna wiadomość----- > > > From: brett lentz > > > Sent: Tuesday, June 07, 2011 6:31 AM > > > To: Development list for Rails: an 18xx game > > > Subject: Re: [Rails-devel] Background Maps > > > > > > I think this is an excellent direction to continue working on. > > > > > > The patch looks like it consolidates a bunch of code into a couple of > > > classes, which looks good on first glance. > > > > > > I'd definitely like to see the finished patch once you're ready for it > > > to be merged into the codebase. > > > > > > ---Brett. > > > > > > On Mon, Jun 6, 2011 at 2:45 PM, Adam Badura <ab...@o2...> wrote: > > > > Sorry for the delay but I decided to adapt the patch to current code > > > > revision and have a look whether it does what I recall it did. Also > > > > I removed some additional works on symbols which I was doing along > > > > (this was the reason to start this work) but would be only > > > > distracting now. > > > > > > > > The code is mostly not documented as it is a working patch. Its not > > > > also "clean". But it does show that SVG Document isn't that hard. > > > > (To scroll or zoom use standard Batik components ways: Shift/Ctrl + > > > > moves with mouse buttons pressed.) > > > > > > > > So what do you think? Should I continue my work in this area? > > > > > > > > Adam Badura > > > > > > > > -----Oryginalna wiadomość----- From: Erik Vos > > > > Sent: Monday, June 06, 2011 2:43 PM > > > > To: 'Development list for Rails: an 18xx game' > > > > Subject: Re: [Rails-devel] Background Maps > > > > > > > > Adam, > > > > > > > > Congratulations with your second child! > > > > > > > > I'm certainly interested to have a look at your code, to check if I > > > > can merge it with my map display code. > > > > > > > > Some more comments below. > > > > > > > >> -----Oorspronkelijk bericht----- > > > >> Van: Adam Badura [mailto:ab...@o2...] > > > >> > > > >> I was working on moving entire drawing to SVG (and this was one > > > >> > > > >> of the reasons I tried to push Batik 1.7). But recently my second > > > >> child was born and there is some little chaos in my life with not > > > >> much time for such tasks. > > > >> I still have SVN Patch yet it is already conflicting at some places > > > >> with new code. > > > >> > > > >> What I managed to get was to create an SVG document containing > > > >> > > > >> map (all the tiles, either from map or track tiles). It looked > > > >> significantly better than our previous drawing mechanism. While it > > > >> was much less and much simpler code. > > > >> Also it scaled nicely. > > > >> > > > >> What the code was missing was: > > > >> (1) drawing station tokens, > > > >> (2) drawing train paths, > > > >> (3) handling scaling and scrolling well, > > > >> (4) support tile selection. > > > >> > > > >> First two would likely require some "hacking" as there is no > > > >> > > > >> easy way currently to do it in SVG Document as there is not > > > >> "specification" of tracks and stations on an SVG tile. But previous > > > >> code did it somehow and I guess that solution could be used with > > > >> SVG Document as well until (if ever) SVG tiles will receive better > > > >> description. (That is a topic interesting on its > > > >> own...) > > > > > > > > The tracks and the token spot locations are also (somewhat > > > > cryptically) defined in Tiles.xml, and these definitions are > > > > currently used to draw the train paths and tokens. > > > > For the time being (or perhaps forever) that can be left as is, > > > > drawing these objects in the top layer of the JLayeredPane that I'm > > > > currently using. > > > > However, that would still require achieving correct alignment of the > > > > two layers after zooming. > > > > > > > >> I tries to handle third by using JSVGSrolledPane (or something > > > >> > > > >> called > > > >> similarly) but didn't achieve much. Then I had to interrupt my > > > >> investigations. > > > > > > > > I have also been thinking about JSVGScrolledPane, but I think using > > > > that will only become possible once we manage to do all drawing via > > > > JSVG. > > > > > >> Fourth should be easy as Batik provides some events to detect > > > >> > > > >> this. I expect this could be even easier then current mouse > > > >> handling. Borders around selected or marked tiles could likely be > > > >> achieved easily with CSS in the SVG Document. > > > > > > > > Sounds good. > > > > > > > > Erik. > > > > > > > > > > > > -------------------------------------------------------------------- > > > > -- > > > > -------- Simplify data backup and recovery for your virtual > > > > environment with vRanger. > > > > Installation's a snap, and flexible recovery options mean your data > > > > is safe, secure and there when you need it. Discover what all the > > > > cheering's about. > > > > Get your free trial download today. > > > > http://p.sf.net/sfu/quest-dev2dev2 > > > > _______________________________________________ > > > > Rails-devel mailing list > > > > Rai...@li... > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > -------------------------------------------------------------------- > > > > -- > > > > -------- EditLive Enterprise is the world's most technically > > > > advanced content authoring tool. Experience the power of Track > > > > Changes, Inline Image Editing and ensure content is compliant with > > > > Accessibility Checking. > > > > http://p.sf.net/sfu/ephox-dev2dev > > > > _______________________________________________ > > > > Rails-devel mailing list > > > > Rai...@li... > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > ---------------------------------------------------------------------- > > > -------- EditLive Enterprise is the world's most technically advanced > > > content authoring tool. Experience the power of Track Changes, Inline > > > Image Editing and ensure content is compliant with Accessibility > > > Checking. > > > http://p.sf.net/sfu/ephox-dev2dev > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > ---------------------------------------------------------------------- > > > -------- EditLive Enterprise is the world's most technically advanced > > > content authoring tool. Experience the power of Track Changes, Inline > > > Image Editing and ensure content is compliant with Accessibility > > > Checking. > > > http://p.sf.net/sfu/ephox-dev2dev > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > ------------------------------------------------------------------------- > > ----- EditLive Enterprise is the world's most technically advanced > > content authoring tool. Experience the power of Track Changes, Inline > > Image Editing and ensure content is compliant with Accessibility > > Checking. > > http://p.sf.net/sfu/ephox-dev2dev > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > --------------------------------------------------------------------------- > --- EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X