4Q-s-r-o / signature

Flutter plugin that creates a canvas for writing down a signature
MIT License
252 stars 83 forks source link

Export toRawSVG dose not working correctly #87

Closed AbdullahSh-25 closed 4 months ago

AbdullahSh-25 commented 1 year ago
  1. I draw separated paths in signature widget
  2. when use toRawSVG it shown as one path

before photo_2023-02-25_15-24-15

after photo_2023-02-25_15-24-20

tonyhart7 commented 1 year ago

Yeah its sucks

MartinHlavna commented 1 year ago

@h7x4 you have implemented svg export and have more insight here. I think the problem is not generating spaces between polylines. Solution would be to check for gaps between points, but you may have better idea.

h7x4 commented 1 year ago

This is a bug with the way the export function uses the list of actions (_latestActions). I assumed that the list would be [ 1st stroke, 2nd stroke, 3rd stroke ], but it turns out that it is saved as [ 1st stroke, 1st and 2nd stroke, 1st 2nd and 3rd stroke ], which causes the SVG to draw overlapping lines.

I'll see if I can make a fix in the upcoming days.

AbdullahSh-25 commented 1 year ago

yes that true i figured out that i fixed it like this way

` final List<List> list = [];

for (int i = 0; i < _latestActions.length; i++) {
  final int val;
  final List<Point> points = [];
  if (i == 0) {
    val = 0;
  } else {
    val = _latestActions[i - 1].length;
  }
  for (int j = val; j < _latestActions[i].length; j++) {
    points.add(_latestActions[i][j]);
  }
  list.add(points);
}`

and when creating polylines string i used this list

it is not the best way but it fix the problem

h7x4 commented 1 year ago

I think the whole underlying data structure should be swapped out with a list of stroke objects in the first place. We are currently using $\mathcal{O}(n^2)$ space to store history, and even if we only fixed that part, we would either have to store everything doubly and allow for the possibility of inconsistent data, or do some finicky list indexing which kinda just unravels parts of the abstraction layer of storing stroke objects in the first place.

See https://github.com/4Q-s-r-o/signature/issues/73#issuecomment-1304297677, just without the part about each stroke having a color.

Do you have any thoughts @MartinHlavna, before I start working on it?

henry2man commented 1 year ago

I can confirm that #91 works better than current pub version, except in terms of color conversion (please see https://github.com/4Q-s-r-o/signature/pull/91#issuecomment-1651080671).

MartinHlavna commented 10 months ago

Sorry I had to focus on different project for some time. I will review and hopefully merge #91 soon.

@h7x4 I agree that some refactoring of data storage is spot on. Some parts of the plugin since first version of plugin.

MartinHlavna commented 4 months ago

91 has been already merged and released. I will close this.