You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we ask the user to change a number that represents spacing, but it doesnt mean anything to them.
The number translates to pixels, but even then its kinda fuzzy because pixels are not created equal.
Instead we want to convert it until a real distance unit, like centimetres.
However, this could also be confusing. If its in a CM and a user prints it at A5 size then the units will be wrong. So maybe we accept its wrong for these edge cases or we make it clear, the size is for A4 prints? Even then there will be some variability on how much border each printer produces.
Its a tough one. We could perhaps opt for a % based system? Although that could be more confusing.
Doing a preview (see #9) would mostly make this irrelevant.
The text was updated successfully, but these errors were encountered:
it can be any old number. Pixels still makes sense. I was wondering “% of a cell” but nah. That’s confusing too
Have a little description that says “= to 2mm at A4 or 1.5mm on a iPad standard display”. I guess if it was on a slider then someone could move it to the right physical size. Realistically it’s only going to be used for printing
Yeah having a good description would help but I always worry about adding long descriptions because people just dont read them or get confused about what they mean no matter how you word it.
After writing the issue my final thought really was to do the live preview then assess if we still need todo this. My suspicion is it wont be needed once we have the live preview
Currently we ask the user to change a number that represents spacing, but it doesnt mean anything to them.
The number translates to pixels, but even then its kinda fuzzy because pixels are not created equal.
Instead we want to convert it until a real distance unit, like centimetres.
However, this could also be confusing. If its in a CM and a user prints it at A5 size then the units will be wrong. So maybe we accept its wrong for these edge cases or we make it clear, the size is for A4 prints? Even then there will be some variability on how much border each printer produces.
Its a tough one. We could perhaps opt for a % based system? Although that could be more confusing.
Doing a preview (see #9) would mostly make this irrelevant.
The text was updated successfully, but these errors were encountered: