Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Still maintained? #1055

Open
rugk opened this issue Oct 17, 2018 · 13 comments

Comments

Projects
None yet
5 participants
@rugk
Copy link

commented Oct 17, 2018

Fedora Magazine claims this tool is not actively developed anymore?

IMHO this does not look like that. Could you clarify this?

@justrhysism

This comment has been minimized.

Copy link

commented Oct 19, 2018

@rugk Your link points to DuckDuckGo...

@rugk

This comment has been minimized.

Copy link
Author

commented Oct 19, 2018

@GreLI

This comment has been minimized.

Copy link
Member

commented Oct 22, 2018

Well, I'd say this claim is correct. I'm doing some things (mostly bugfixing) from time to time, but have a little time to develop.

@justrhysism

This comment has been minimized.

Copy link

commented Oct 22, 2018

Invite some new maintainers/collaborators on board? Seems plenty of people are keen to contribute.

@GreLI

This comment has been minimized.

Copy link
Member

commented Oct 28, 2018

Not many people are really interested in it, unfortunately.

@justrhysism

This comment has been minimized.

Copy link

commented Oct 28, 2018

⭐️ 10,000+ stars on GitHub, surely there is.

@shoogle

This comment has been minimized.

Copy link

commented Nov 1, 2018

@GreLI, you could start by putting someone else in charge of a new semi-official repository just for plugins, then you would only have to maintain the core plugins and the API.

This would speed up development of new plugins while keeping the core code safe. You can merge the most popular plugins into the core once the bus have been ironed out in the other repo.

@GreLI

This comment has been minimized.

Copy link
Member

commented Nov 5, 2018

Plugins is the least of problems. A major rewriting is needed to get significant improvement and to fix some issues.

@shoogle

This comment has been minimized.

Copy link

commented Nov 5, 2018

@GreLI, could you link to the relevant issues in the tracker, or maybe label them as "priority", or apply a milestone, or something like that? It would be good to have some idea what needs doing.

@GreLI

This comment has been minimized.

Copy link
Member

commented Nov 8, 2018

It's just ideas, not really specified. Some pieces of them can be seen here or there. Some quick thaughts:

  1. Better parser. Currently sax-js is used, but it has limitations. E.g. some work is needed to preserve white-space (with xml-preserve or white-space style). Also, parse path data syntax, styles, etc. Perhaps lazy.
  2. Better plugins system. Now it works consequently and therefore have issues with order of execution. E.g. some plugin is best to run after another in some case, and with directly opposite order in another. Could be event driven (e.g. collapseGroups may execute as soon as there is some <g> without attributes after some transformations).
  3. Plugin system should work not only on elements, but with path data.
  4. Some better API. E.g. quick check for next node in path data regardless of whether there a start or end of path.
  5. It would be nice to have CSS object tree along with document tree for styling checks. E.g. not every transformation can be applied in presence of strokes.
@GreLI

This comment has been minimized.

Copy link
Member

commented Nov 9, 2018

Also, could be cool if core automatically apply every action to check whether it efficient or should be reverted.

@shoogle

This comment has been minimized.

Copy link

commented Dec 8, 2018

@GreLI, the tool you have created is already very good (the best one I know of, in fact) so don't go tearing everything up and starting from scratch!

  1. Don't bother with this; it was a mistake to include whitespace preservation in the XML specification. If somebody finds a library that handles whitespace preservation (most don't and for good reason) then they are welcome to implement this, but otherwise don't bother.

    • Whitespace preservation is a relic due to XML's origins as a markup language like HTML, but has it has no place in a data serialization format, which is what XML is mainly used for these days.
    • The main issue is that whitespace is sometimes considered semantic (i.e. part of the data) and sometimes not (i.e. just fancy indentation to make it easy to read). If it was always one or the other it would be fine, but both is unacceptable.
    • Side note: SVG's <tspan> element exists mainly as a way to avoid having to use whitespace preservation in the first place.
  2. An event-driven plugin system would be nice, but probably requires a major rewrite. It might be worth experimenting with on a separate branch, but no need to throw away the current system just yet as it works very well in most cases.

  3. I don't think the current API handles any path data (maybe just a few things?) so all path manipulations are left to the plugins. I can see why path features would be nice to have, but you could just as easily argue that it is out-of-scope. Why not let somebody else create a path manipulation API and then you can add it as a submodule or something like that?

  4. Same as 3.

  5. Again, this would be nice but it is starting to sound like you want to just write a whole SVG manipulation library rather than focussing on optimizations that are simple and safe. (And anyway, surely there is already a library you could use?)

  6. (automatic efficiency checks) This probably isn't too hard to do.

You already said you don't have time to properly maintain it as it is, so maybe your priority should be to implement features that reduce your workload, not increase it 😉 If you simply allowed plugins to be loaded from outside the project folder that would at least allow plugin to development to continue without requiring input from you, which would leave you free to work on the API.

Might you consider giving somebody else commit access to the main repository? Or you could give the person access to a side repository for plugins, or something like that. (I'm also too busy to get involved, in case you were wondering, but I might be able to help you find somebody who would be interested.)

If you are truly unable to carry on then you need to put some kind of notice in the README and GitHub project description because it's not fair to let people carry on submitting issues and PRs that go unnoticed.

@strarsis

This comment has been minimized.

Copy link
Contributor

commented Apr 4, 2019

@shoogle: Using jsdom would probably also get rid of many redundancies like the code introduced by the inlineStyles plugin. There should be an object tree by jsdom or at least some library that can run on top of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.