Use case
Closed this issue · 7 comments
I am missing something like a use case!
For example a possiblity to create a station in browser and download either the tex source or a png of that station afterwards.
What you describe would be in my opinion the next step in the trackschematic universe with an own project. For this new project there could be a webapp where you can draw a station, tracks etc. and - like you described it - export it to tex code, png / jpeg or svg. For the svg export this project could be used.
The goal of this project is to simplify the creation of trackschematics with svg on a lower level. For example you could create an svg like this (dummy code) and it displays two tracks with a turnout. As you might notice I try to have the syntax and units as close to the tikz package I can get.
<svg viewBox="0 0 2 2" xmlns="http://www.w3.org/2000/svg">
<polyline points="0,0 1,0 2,-1" class="maintrack" />
<polyline points="1,0 2,0" class="maintrack" />
<use href="#turnout" x="1" y="0" class="backward right points-left" />
<use href="#bufferstop" x="2" y="0" />
</svg>At this stage its not for web beginners, but it uses standarized svg (browser) syntax. With this low level notation animation, javascript interaction and custom styling will be possible. And due to this small abstraction layer its still receives updates and bug fixes. I am still in a concept phase so the syntax may change.
In general there are three possibilities to include svgs into a website:
- Inline SVG
- Reference it by
<object src=""> - Reference it by
<img src="">
Option 1 and 2 can be achieved by a really short and fast js snippet. JS can't access SVGs in image tags, so for solution 3 there has to be a possiblity for command line usage that you can integrate in the build process.
When a tool, what you described, exists I think it does make sense to have the export with this more readable syntax. Then also web beginners could use this syntax and still receive updates and bug fixes.
I hope it helped you to understand the goal of this project.
It would be great if you would share your thoughts on this.
Now it makes more sense! It would probably help to include your main goal together with a minimal working example in your documentation.
I also see the need to divide a "language" for the lower level and an "app" for higher level user interaction.
If the syntax and the units have to deviate too far from the tikz variant because of the svg environment, it may also make sense to rethink the tikz syntax and change it.
For now it was really straight forward to implement the tikz syntax.
What I changed so far is that there are defaults to face (default=forward) and branch (default=left [I think right makes more sense. I'll change that]). In the web there's no compilation step like in Latex so there's no good way to show errors like "Please add a face direction".
Regarding the syntax I'm not quite sure whats better: To use data attributes or classes. For example class="points-left" vs data-points="left". Class syntax is a bit shorter, but data attributes are closer to tikz and maybe more readable. If one would choose data attributes over classes, how would one handle binary options like fouling-point? An empty data attribute like data-fouling-point="" or use a class?
It's also possible to have binary options as classes and non-binary as data attributes, but that could get a little bit messy.
What do you think is the best way? I am really unsure about this.
The example above in the two variants:
class only
<svg viewBox="0 0 2 2" xmlns="http://www.w3.org/2000/svg">
<polyline points="0,0 1,0 2,-1" class="maintrack" />
<polyline points="1,0 2,0" class="maintrack" />
<use href="#turnout" x="1" y="0" class="backward right points-left" />
<use href="#bufferstop" x="2" y="0" />
</svg>data attribute only
<svg viewBox="0 0 2 2" xmlns="http://www.w3.org/2000/svg">
<polyline points="0,0 1,0 2,-1" data-maintrack />
<polyline points="1,0 2,0" data-maintrack />
<use href="#turnout" x="1" y="0" data-face="backward" data-branch="right" data-points="left" />
<use href="#bufferstop" x="2" y="0" />
</svg>SVG is not so familiar to me. Is it possible to mix data attributes and classes? On the other hand mixing syntax is leading to misunderstandungs and clutter.
Data attributes seems to be working with the polyline as a lean syntax.
But in case ot the turnout it seems more complicated and even misleading: what is a "data-points"? (rhetorical)
Even if there are defaults, I would include them to make the code explicitly readable without having to know the defaults.
<svg viewBox="0 0 2 2" xmlns="http://www.w3.org/2000/svg">
<use href="#bufferstop" x="2" y="0" class="forward"/>
</svg>For boolean values like the fouling point, I would use a default value with false and classes that is set the value true when class="fouling-point" is used. Does this makes sense or am I missing something?
Yes, its possible to mix data attributes and classes.
I think I will stay with classes only. It looks cleaner and more consistent and as far as I can tell, there is no technical advantage using data attributes in this case. For consistency I am going to rename right and left class to branch-right and branch-left. I will also add face-backward and face-forward as aliases like in the tikz package.
Really good point with the defaults! I also will keep the defaults undocumented.
So it would like this
<svg viewBox="0 0 2 2" xmlns="http://www.w3.org/2000/svg">
<polyline points="0,0 1,0 2,-1" class="maintrack" />
<polyline points="1,0 2,0" class="maintrack" />
<use href="#turnout" x="1" y="0" class="backward branch-right points-left" />
<use href="#bufferstop" x="2" y="0" class="forward" />
</svg>I adapted all the things we discussed above.
#13 is a sepearate issue