This PR prevents a crash when you try to curve an arrow that is pointing
a very small distance.
Fixes#1533
### Change Type
- [x] `patch` — Bug Fix
### Test Plan
1. Draw a line.
2. Draw an arrow from one point on the line to another point on the
line.
3. It might look weird or flicker (that's ok - that's a *different*
issue - we can fix it another time).
4. Move the middle handle of the arrow.
5. It should curve the arrow.
---
1. Open this snapshot link:
https://www.tldraw.com/s/v2_c_LtB3kVSYEyWuR-aCCrrUn
2. Copy its contents onto your own tldraw.
3. Click on the frog.
4. Drag the handle that's on the frog's face.
5. It shouldn't crash the app.
- [ ] Unit Tests
- [ ] Webdriver tests
### Release Notes
- Fixed a rare crash that could happen when you try to curve an arrow
with zero distance.
This PR fixes points on resize as well as on create. This should help
with file size for large resizes.
### Change Type
- [x] `patch` — Bug Fix
### Test Plan
- [ ] Unit Tests
This PR replaces our `console.log` with `nicelog` so that I can more
easily grep for errant console.logs.
### Change Type
- [x] `internal` — Any other changes that don't affect the published
package (will not publish a new version)
This diff modifies our canvas/rendering code to support shapes rendering
into a "background layer". The background layer isn't a layer in the
sense of our own html/svg/indicator layers, but is instead part of the
HTML canvas layer and is created by allocating z-indexes to shapes below
all others.
For most shapes, the background starts at the canvas. If a shape is in a
frame, then the frame is treated as the background.
Exports now use the `renderingShapes` algorithm which fixed a small bug
with exports where opacity wouldn't get correctly propagated down
through child shapes.
### The plan
1. initial highlighter shape/tool #1401
2. sandwich rendering for highlighter shapes #1418 **>you are here<**
3. shape styling - new colours and sizes, lightweight perfect freehand
changes
### Change Type
- [x] `minor` — New Feature
### Test Plan
not yet!
- [x] Unit Tests
### Release Notes
[not yet!]
This PR removes unused scripts related to benchmarking, and some other
unused dependencies.
### Change Type
- [x] `internal` — Any other changes that don't affect the published
package (will not publish a new version)
This diff fixes a number of issues with text export by completely
overhauling how we approach laying out text in exports.
Currently, we try to carefully replicate in-browser behaviour around
line breaks and whitespace collapsing. We do this using an iterative
algorithm that forces the browser to perform a layout for each word, and
attempting to re-implement how the browser does things like whitespace
collapsing & finding line break opportunities. Lots of export issues
come from the fact that this is almost impossible to do well (short of
sending a complete text layout algorithm & full unicode lookup tables).
Luckily, the browser already has a complete text layout algorithm and
full unicode lookup tables! In the new approach, we ask the browser to
lay the text out once. Then, we use the
[`Range`](https://developer.mozilla.org/en-US/docs/Web/API/Range) API to
loop over every character in the rendered text and measure its position.
These character positions are then grouped into "spans". A span is a
contiguous range of either whitespace or non-whitespace characters,
uninterrupted by any browser-inserting line breaks. When we come to
render the SVG, each span gets its own `<tspan>` element, absolutely
positioned according to where it ended up in the user's browser.
This fixes a bunch of issues:
**Misaligned text due to whitespace collapsing at line breaks**
**Hyphenated text (or text with non-trivial/whitespace-based breaking
rules like Thai) not splitting correctly**
**Weird alignment issues in note shapes**
**Frame labels not respecting multiple spaces & not truncating
correctly**
#### Quick note on browser compatibility
This approach works well across all browsers, but in some cases actually
_increases_ x-browser variance. Consider these screenshots of the same
element (original above, export below):
Notice how on chrome, the whitespace at the end of each line of
right-aligned text is preserved. On safari, it's collapsed. The safari
option looks better - so our manual line-breaking/white-space-collapsing
algorithm preferred safari's approach. That meant that in-app, this
shape looks very slightly different from browser to browser. But out of
the app, the exports would have been the same (although also note that
hyphenation is broken). Now, because these shapes look different across
browsers, the exports now look different across browsers too. We're
relying on the host-browsers text layout algorithm, which means we'll
faithfully reproduce any quirks/inconsistencies of that algorithm. I
think this is an acceptable tradeoff.
### Change Type
- [x] `patch` — Bug Fix
### Test Plan
* Comprehensive testing of text in exports, paying close attention to
details around white-space, line-breaking and alignment
* Consider setting `tldrawDebugSvg = true`
* Check text shapes, geo shapes with labels, arrow shapes with labels,
note shapes, frame labels
* Check different alignments and fonts (including vertical alignment)
### Release Notes
- Add a brief release note for your PR here.
