For Issue 187. This is a more fully featured implementation than Pull Request 725.

I need this feature for my product, so I fully intend to support this class if it is made official.

Demo

Check it out a demo.

Summary of features

• Subclasses IText, so gets all of its goodness.
• Text wraps as user types and/or resizes a Textbox. Works with all textAlign values.
• User can change width of Textbox. Height is automatically set based on text wrapping. Font size and scale does not change.
• Support for resizing in Groups. Only the width of a Textbox changes. The Textbox updates its scaleX/Y values to undo scale values of its parent Group so that font size remains the same.
• Refactored the ton of this.text.split(this._reNewline) calls into a function that gets overwritten by subclasses.
• Fixed bug in Justify text (was present in both Text and IText classes).
• Tested on latest versions of Safari (OSX & iOS), Chrome (OSX & Win), Firefox and Internet Explorer.

Open issues / TODOs

1. Need to add support for Styles. It is not required for my usage of this widget so contributions are welcome.
2. ~~Justify alignment needs to be fixed in IText.~~
3. ~~Inheritance bug in IText.toSVG(). The callSuper in _setSVGTextLineText goes into a recursive loop if called on a Textbox object. It works fine if I replace the callSuper call with a call to a copy of Text._setSVGTextLineText. Have you encountered something like this before? Any opinions on how to fix this?~~

Please list changes that you'd like me to make before this can be made official. I saw in the other pull request that @kangax wasn't too sure about the 'Textbox' name ... we can change it.

Hi

Loving the product but we desperatly need curve text. I've seen that it's on the roadmap but would like to ask if there is any progress or anything that can be done to help?

Great work guys!

There is a $200 open bounty on this issue. Add to the bounty at Bountysource.

I wasn't sure if a site redesign is still on the table — it is mentioned here: https://github.com/kangax/fabric.js/wiki/Love-Fabric%3F-Help-us-by... — but I started to put something together that simplifies the homepage and encourages people to start with the tutorial or downloading the library.

I think simplifying the features that are showcases on the home page, as users can easily click through to the full demos page.

There are still some items that need to be added back in (twitter, github, flattr, etc.), but it is a start. If this is an acceptable first stab I will do some additional identity exploration and work to refine the design.

There is a $305 open bounty on this issue. Add to the bounty at Bountysource.

Posibility to zoom canvas (+/-) and all it's objects.

Here are some ideas from @kangax:

1. Programmatic canvas zooming One zoom level property (1 by default = normal zoom)
2. UI for canvas zooming UI is a secondary thing; we can do it after implementing programmatic zooming. For this, we'll probably need to introduce another canvas mode, similar to free drawing mode. When in that mode, canvas would zoom on click or dblclick or whatever. You wouldn't be able to select objects (similar to free drawing mode).

I like how zoom works in google docs. I think we should base off of that.

Other ideas:

• Touch device compatibility: Zoom in/out with touch

The $1,091 bounty on this issue has been claimed at Bountysource.

General

Adds support for native like text dragging! Out of the box! This PR aims to support text dragging, making fabric's text objects feel/behave like a HTML textarea. It is an expected interaction from the user's point of view.

closes #7800

Changes

• drag/drop event logic on canvas/text:
  • firing DnD events with more data for the dev
  • addressed an issue with firing order on drag over targets and the selected target
  • onDragStart and canDrop are public methods for overriding that control drag and drop respectively
  • dragStart logic cycle - imitates spec, invokes target's onDragStart method, if result is true drag starts. Behaves like onSelect.
  • creating a drag image from onDragStart
  • dragEnd calls _onMouseUp synthetically - the browser doesn't do it and fabric needs it to finalize interaction logic
• cursor/selection rendering on text - in order to render text selection on the drag source while dragging and the cursor on the drop target while dragging over it (same as what the browser does)

Thoughts

I think we ought to change the selectWord method to align with the behavior of html textarea which selects the word and all the trailing whitespace (it's important for drag and drop).

TO DO

• [x] perhaps wait for #7842 for DragEvent.dataTransfer
• [ ] retina scaling for drag image - couldn't manage to fix the blur (will be handled in a follow up if ever)
• [x] #7904

Related Issues

• https://github.com/fabricjs/fabric.js/issues/8025
• https://github.com/fabricjs/fabric.js/issues/7847
• #7478

Proposed changes

• ~~Created acos function in fabric.util to ensure the value is in the range [-1, 1] and the calcAngleBetweenVectors function is using it. This was causing a bug (see comment on commit bc93beb)~~
• ~~In calcAngleBetweenVectors function, replaces Math.hypot(x, y) with Math.sqrt(x*x + y*y) to ensure equal results in both engines: Firefox and Chrome. (see comment on commit bc93beb)~~
• ~~In getBisector function, checks if ro is close to zero instead of being strictly equal.~~
• In calcAngleBetweenVectors function, calculate angle between two vector using atan2 instead of dot product. So eliminated the need to check the angle direction in getBisector function,
• Changed the _setPositionDimensions function in the polyline class to adjust the width/height by the scale in case of uniform stroke.
• Changed the projectStrokeOnPoints function to cover all stroke line join cases and also to uniform stroke. This function deserves further comment:

In the case of open path, the stroke is rendered differently, so I calculated with the vectors orthogonal to the stroke.

In the case of the bevel, they are the points formed by the orthogonal to the vertex

In the case of the round, ~~if the angle is less than or equal to 90°,~~ the projection is calculated with two vectors parallel to the X and Y axes. ~~In the case of larger angles, it is calculated using the orthogonals.~~

In the case of the miter, is the same calculation commented here: https://github.com/fabricjs/fabric.js/issues/8025

For a better view, see this link (you can change the vectors direction by holding the red circles) : https://hypertolosana.github.io/efficient-webgl-stroking/index.html

Screenshots

Working example here: https://codesandbox.io/s/project-stroke-points-with-context-to-trace-b8jc4j?file=/src/index.js

The red dotted vector is the bisector returned by the getBisector function. The green dotted vector is in the opposite direction and is what is used to determine which side to plot the projections. The projections are the colored vectors, one color for each point. To make debugging easier, you can configure the parameters (stroke line join type, strokeUniform, miterLimit, etc..)

openPath = false and strokeUniform = true

| Angle | Miter | Round | Bevel | |----------|:-------------:|:-------------:|:-------------:| | less than 90° | | | | greater than 90° | | | | equal to 180° | | | |

Regarding https://groups.google.com/forum/?hl=en#!topic/fabricjs/N5LOujX-qMA it would be great to have an option for better resampling when scaling images with fabric:

It looks like fabric.js currently uses only the browser's native/default (bilinear?) resampling capabilities, which usually result in very pixelated, low-quality images when scaling down.

I would like to request a feature that avoids pixelation and resamples images to a higher quality especially when scaling down (similar to http://jsfiddle.net/qwDDP/), e.g. when the user uses the scaling handles on an image element in a fabric.js canvas, or when the scaleX/Y or width/height properties are used.

Depending on performance impact, this could happen during scaling, or when scaling has completed, but should yield a high quality scaled image in any case.

Addendum: As far as text resampling suffers the same issue (which it may not), it would be ideal if that was addressed as well.

The $300 bounty on this issue has been claimed at Bountysource.

I migrated the PR https://github.com/fabricjs/fabric.js/pull/8083/ code to typescript and corrected the calculation when there is skew.

closes #8083

Related Issues

• https://github.com/fabricjs/fabric.js/issues/8025
• https://github.com/fabricjs/fabric.js/issues/7847
• #7478

Proposed changes

• In calcAngleBetweenVectors function, calculate angle between two vector using atan2 instead of dot product. So eliminated the need to check the angle direction in getBisector function,
• Changed the _setPositionDimensions function in the polyline class to adjust the width/height by the scale/skew.
• Changed the projectStrokeOnPoints function to cover all stroke line join cases and also to uniform stroke.

Working example

The red dotted vector is the bisector returned by the getBisector function. The green dotted vector is in the opposite direction and is what is used to determine which side to plot the projections. The projections are the colored vectors, one color for each point. To make debugging easier, you can configure the parameters (stroke line join type, strokeUniform, miterLimit, etc..)

Documentation

This section details the calculation of projections for each type of stroke line join.

Summary

• 1. Open path
  • 1.1 Butt
  • 1.2 Round
  • 1.3 Square
• 2. Closed path
  • 2.1 Miter
  • 2.2 Bevel
  • 2.3 Round
    • 2.3.1 Round without skew
    • 2.3.2 Round with skew

Links:

• MDN: https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/stroke-linejoin
• Spec: https://svgwg.org/svg2-draft/painting.html#StrokeLinejoinProperty
• Playground to understand how the line joins works: https://hypertolosana.github.io/efficient-webgl-stroking/index.html

1. Open path

These cases differ in relation to the line-cap property (MDN reference)

1.1 Butt

The projections are calculated by two vectors orthogonal to the stroke.

Scaling effect: only when the stroke is uniform that scaling affects the calculation of projections. It changes the position of the points (see more details here), so we must take it into account to have the new arrangement of the points.

Skew effect: just apply distortion after projection calculation.

1.2 Round

Same as 2.3 Round

1.3 Square

Project a rectangle of points on the stroke in the opposite direction of the vector AT. The projections are the two vectors starting from the vertex pointing to the sides of the square.

Scaling effect: only when the stroke is uniform that scaling affects the calculation of projections. It changes the position of the points (see more details here), so we must take it into account to have the new arrangement of the points.

Skew effect: just apply distortion after projection calculation.

2. Closed path

There are three types of stroke line join (MDN reference)

2.1 Miter

The corner is formed by extending the outer edges of the stroke at the tangents of the path segments until they intersect.

Stroke miter limit: when two line segments meet at a sharp angle, it is possible for the join to extend, far beyond the thickness of the line stroking the path. The stroke-miterlimit imposes a limit on the extent of the line join, if so the join is converted from a miter to a bevel. (MDN reference)

The ratio of miter length (distance between the outer tip and the inner corner of the miter) to stroke-width is directly related to the angle (alpha) of the bisector:

$strokeMiterLimit = \frac{miterLength}{strokeWidth} = \frac{1}{sin(\alpha)}$

Note: when the stroke is uniform, the arrangement of the points is changed (see explanation below), consequently the strokeMiterLimit. In this case we must recalculate this limit.

Scaling effect : scaling changes the arrangement of points, hence the bisector calculation. Take a look:

Plotting a triangle with the points:

A (0, 0)
B (50, -200)
C (100, 0)

The angle of the bisector is alpha.

But when I apply a scaling of 2 only on the X axis, the angle of the bisector changes (beta < alpha), hence the miter vector too. To calculate this new angle we must apply the scaling on the points to find the new vectors that form A, B and C.

scaleX = 2 ; scaleY = 1

scaled A (0 * scaleX , 0 * scaleY) --> (0, 0)
scaled B (50 * scaleX, -200 * scaleY) --> (100,-200)
scaled C (100 * scaleX, 0 * scaleY) --> (200,0)

With these vectors we were able to correctly calculate the miter vector.

Skew effect: just apply distortion after projection calculation.

2.2 Bevel

The projections are both orthogonal to the vertex:

Scaling effect: only when the stroke is uniform that scaling affects the calculation of projections. It changes the position of the points (see more details here), so we must take it into account to have the new arrangement of the points.

Skew effect: just apply distortion after projection calculation.

2.3 Round

This case has calculation of projections differently if there is or not the presence of skew.

2.3.1 Round without skew

The projections are the two vectors parallel to the X and Y axes.

Scaling effect: does not directly affect projections (only stroke size).

2.3.2 Round with skew

Projections are the points furthest from the vertex in relation to the direction of the X and Y axis respectively. See the example below.

Consider this case:

There is a point $(X_i, Y_i)$ that will be the furthest Y (max Y) distance from the origin after applying skewY. This is our point of interest.

We have:

[eq.1] $Y_{afterSkewY} = Y_i + X_i * Tan(skewY)$

And we know that $X_i$ is a function of $Y_i$:

$Y_i^2 + X_i^2 = r^2$ [eq.2] $X_i = \pm \sqrt{r^2 - Y_i^2}$

Substituting eq.2 in eq.1 we have:

$Y_{afterSkewY} = Y_i \pm \sqrt{r^2 - Y_i^2} * Tan(skewY)$

So we have an equation in terms of just Y:

$f(Y_i) = Y_i \pm \sqrt{r^2 - Y_i^2} * Tan(skewY)$

The plus/minus sign represent both sides of the circle after skewY:

The furthest Y after skewY (max Y) distance from the origin are the maximum/minimun of $f(Y_i)$:

Computing $f'(Y_i)=0$ for both cases, we find:

$Y_i = \pm \frac{r}{\sqrt{1 + Tan^2(skewY)}}$

Substituting $Y_i$ into the circle equation, we find $X_i$:

$X_i = \pm \sqrt{r^2 - Y_i^2}$

That's our solution:

We found the furthest point on the Y axis, now we need to calculate the furthest point on the X axis:

In this case we have to take into account that if there is skewY it will affect skewX. The canvas first applies skewY and then applies skewX, so the point $(Xi, Yi)$ after applying skewX and skewY will look like this:

1. First apply skewY: $(Xi, Yi + Xi * Tan(skewY))$
2. Second apply skewX: $(Xi + (Yi + Xi * Tan(skewY)) * Tan(skewX), Yi + Xi * Tan(skewY))$

That is, skewX is dependent on the result of skewY.

So the equations we have to solve are:

[eq.1] $X_{afterSkewX} = X_i + Y_i * Tan(skewX)$

[eq.2] $Y_i = \sqrt{r^2 - X_i^2} \mp X_i * Tan(skewY)$

Substituting eq.2 into eq.1:

$X_{afterSkewX} = X_i + \sqrt{r^2 - X_i^2} * Tan(skewX) \mp X * Tan(skewY) * Tan(skewX)$

Computing $f'(X_i)=0$ for both cases, we find:

$X_i = \frac{r^2}{1 + \frac{Tan^2(skewX)}{(\pm Tan(skewX) * Tan(skewY) - 1)^2}}$

Scaling effect: in the case of stroke uniform, we must remove the effect of the scale in the calculation of the farthests points,. Because of this, the equations are slightly modified.

Calculating the furthest point on the Y axis:

[eq.1] $Y_{afterSkewY} = Y_i * (1/scaleY) + X_i * (1/scaleX) * Tan(skewY)$

[eq.2] $X_i = \pm \sqrt{r^2 - Y_i^2}$

Substituting eq.2 into eq.1:

$Y_{afterSkewY} = Y_i * (1/scaleY) \pm \sqrt{r^2 - Y_i^2} * (1/scaleX) * Tan(skewY)$

Computing $f'(Y_i)=0$ for both cases, we find:

$Y_i = \pm \frac{r * 1/scaleY}{\sqrt{(1/scaleY)^2 + (1/scaleX)^2 * Tan^2(skewY)}}$

Calculating the furthest point on the X axis:

[eq.1] $X_{afterSkewX} = X_i / scaleX + Y_i * Tan(skewX)$

[eq.2] $Y_i = \sqrt{r^2 - X_i^2} / scaleY \mp X_i * Tan(skewY) / scaleX$

Substituting eq.2 into eq.1:

$X_{afterSkewX} = X_i / scaleX + \sqrt{r^2 - X_i^2} * Tan(skewX) / scaleY \mp X_i * Tan(skewY) * Tan(skewX) / scaleX$

Computing $f'(X_i)=0$ for both cases, we find:

$X_i = \frac{r^2}{1 + \frac{Tan^2(skewX) * scaleY^2}{(scaleX \mp scaleX * Tan(skewX) * Tan(skewY))^2}}$

TO DO

• [x] Bring here all the documentation that is in the PR https://github.com/fabricjs/fabric.js/pull/8083/
• [x] Handle the case when skewX and skewY are applied at the same time when stroke line join is round (still buggy)
• [x] Handle open path with strokeLinecap equals round and square
• [x] Check if in the _set function when skew is applied, I need to invoke dimensioning for all line type joins
• [x] Adjust http://fabricjs.com/custom-controls-polygon to work correctly with skew (another PR) https://github.com/fabricjs/fabric.js/pull/8556
• [x] handle 1 point edge case: round projection?

Currently resizing a text element simple scales the text. This shouldn't be the case, instead resizing should re-define the bounding box around the text.

You should also be able to change the behaviour of text overflow. This should be defined with a new (set|get)textOverflow property. Similar to the text-overflow CSS3 attribute. see: https://developer.mozilla.org/en/CSS/text-overflow

Similarly wrapping behaviour should be defined by the use of a new (set|get)wordWrap property. Similar to the CSS3 word-wrap attribute. See: https://developer.mozilla.org/en/CSS/word-wrap

Having it this way also then makes more sense for the textAlign properties. Text alignment should then be relative to the bounding box. Not the whole canvas! I'm not sure how you use these at the moment, but it's confusing none the less.

I know re-writing the text element to remove cufon dependency is high on the Todo list, so when you start doing that if you could include the above changes I'd really appreciate it. Also looking forward to removing cufon, being able to use any css font will be so much better.

I'd be happy to help contribute but I have no idea how far through the rewrite you already are. Please advise when/where you'd need help doing this.

Thanks

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@melchiar This PR contains the progress of text on a path, that i started right now. i ll push up every time i do a small progress.

closes #729 closes #5900 closes #2544

This is the more updated code.

closes #1814, #1897, #1905, #1581, #1940 Current situation: Current iText Drawing, showing BackGroundColor, TextBackgroundColor, selection behaviour

desired behaviour ( more or less )

As of now this code changes the behaviour in this way: normal text:

itext:

CheckList

• [X] I agree to follow this project's Code of Conduct
• [X] I have read and followed the Contributing Guide
• [X] I have read and followed the Issue Tracker Guide
• [X] I have searched and referenced existing issues and discussions
• [X] I am filing a BUG report.
• [X] I have managed to reproduce the bug after upgrading to the latest version
• [X] I have created an accurate and minimal reproduction

Version

5.3.0

In What environments are you experiencing the problem?

Chrome

Node Version (if applicable)

None

Link To Reproduction

http://fabricjs.com/using-transformations

Steps To Reproduce

1. open http://fabricjs.com/using-transformations
2. bind minion to boss
3. rotate the boss for several times and stop at a specific angle

Expected Behavior

the minion 's left and top is aligned to the boss

Actual Behavior

the top / left is not aligned to the boss

Error Message & Stack Trace

No response

Motivation

Finishing up basic object migration.

Description

• change the public properties to declare so that any transpiler understand those should be removed.
• ~~added the default values in the constructor, while still making possible to change them globally before initialization of objects~~ failed / scope blown up
• ~~cacheProperties and stateProperties needs to stay on prototype, having them as static is not really possible since it would require duplicating them for each class and would add another constrain when subclassing. Apparently static properties aren't usable with inheritance~~ failed / scope blown up
• Fixed as much as possible TS complains, a couple have been ignored
• Object._removeTransformMatrix moved as utility since is used only from the svg parser

Changes

• removed Object.centerObject and similar. The methods were aliases for canvas counterparts with the added variable that they would be no-op if there wasn't a canvas. Seems jus confusing. Developers should call those methods from the canvas instance instead of relying on the fact that the canvas is maybe there maybe not and the code won't do nothing but won't fail

Gist

In Action

Motivation

This update seems to have no side effects on the build Just a reference branch to experiment with using exports

Description

Changes

Gist

In Action

Description

Custom poly controls as part of fabric.js core.

Fixes:

• Poly with skew
• Poly with flip
• Poly with strokeUniform

Closes: https://github.com/fabricjs/fabric.js/issues/8359

Gist

  const poly = canvas.getActiveObject();
  poly.controls = fabric.controlsUtils.PolyControl.createPolyControls(
    poly.points.length, 
    { cursorStyle: 'crosshair' } //pass custom options
  );
  canvas.requestRenderAll();

In Action

~~https://codesandbox.io/s/custom-control-poly-95y2im~~

https://codesandbox.io/s/custom-control-poly-fix-flip-95y2im

CheckList

• [X] I agree to follow this project's Code of Conduct
• [X] I have read and followed the Contributing Guide
• [X] I have read and followed the Issue Tracker Guide
• [X] I have searched and referenced existing issues and discussions
• [X] I am filing a BUG report.
• [X] I have managed to reproduce the bug after upgrading to the latest version
• [X] I have created an accurate and minimal reproduction

Version

5.3.0

In What environments are you experiencing the problem?

Chrome

Node Version (if applicable)

14.19.3

Link To Reproduction

https://jsfiddle.net/huylv177/62rwofk5/12/

Steps To Reproduce

1. I use fabric.Image.fromURL(base64) to add image to canvas, but sometime its show empty page. I logged callback from fromURL function below:

• When website show empty canvas

• When website show correct image

Expected Behavior

Show correct image

Actual Behavior

Show nothing

Error Message & Stack Trace

No response

Motivation

I would like the animation code and interface to be simpler. So i m proposiing some simplificaiton, it makes also documenting animation easier.

Description

Removal some flexibility in the api in exchange of some code semplification

i also create a folder parkinglot where i put the straighten code and i think i m putting the canvas effects too. Those needs to be changed in examples or something that the developer can grab, but i don't think they should be part of af the class itself. We have 4 effects, while the possibilities are so many that i think providing 4 of them and nothing else just makes noise.

Other things i would like to solve:

• keypath in animation. I don't have a solution right now but ideally i would like to list the cases in which a keypat is needed ( gradients i m sure and little else probably )
• duality between byValue and endValue, i would like to keep one only.

Changes

• Object.animate takes only an object with one or more properties
• animate does not take += or -= anymore, we can write an addition or subtraction when we do the animation end value.
• removed barrel imports
• Object.animate does not undefine anymore the onChange and onComplete of multiple keys. Reasons are that with requestRenderAll that is not needed anymore, and since you can cancel a single animation, if you cancel the one that carry the actual callbacks the others are not working anymore. We need to be clear on the fact that you shoudn't do expensive things on onChange and that you should use requestRenderAll rather than renderAll.

Some other proposals

naming changes

export type TOnAnimationChangeCallback<T, R = void> = (
  value: T,
  valueRatio: number,
  durationRatio: number
) => R;

into

export type TOnAnimationChangeCallback<T, R = void> = (
  value: T,
  valueProgress: number,
  timeProgress: number
) => R;

Reason: ratio is generic, can be 3, 4, -3 0.5. We have values here that are always between 0 and 1 and represent the progress between start and end. I think this naming would be more clear.

Gist

In Action