-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Custom Font .width & .height not accurate #1108
Comments
@kirschkern , i report here your issue from #1844 The text element can be larger than its actual width property so the text has some overflow. See it here => http://jsfiddle.net/tQCTd/5/ on the "r" character. The selection border, which visualizes the elements width, "cuts" off the "r" at the right side. I need this as I use the text element only as a wrapper to draw on a hidden canvas, get the image data from it and do some image manipulation on it. (Mainly removing anti-aliasing and adding a border.) However, when using the width of the text element to size my hidden canvas, some characters get cut off. |
add issue #664 and close it |
add issue #1878 |
Some fonts like for example Pacifico have kerning set no to the letter width but a little bit smaller so that letters can connect with each other. In browsers If not using OpenType.js there is also problem with calculating text height. Right now you make assumption that text height is equal to font size but it's not true in all cases. In new specification of HTML there is extended measureText function. With this function you can calculate real value of font height but it's not supported by any browser. There are polyfills for that. The one I'm right now creating https://github.com/jagi/measure-text-polyfill but it's not yet ready. There is nice polyfill https://github.com/motiz88/canvas-text-metrics-polyfill but it's not compatible with standard and there will be some problems in Node.js. NodeCanvas has extended Concluding, in my opinion the best option would be using OpenType.js. |
I confirm that this issue is still blocking. Anyone working on it ? What do you think about the solution using opentype.js ? Thanks |
+1 for opentype it works quite well for font rendering especially nodejs + windows to avoid having to include pango/freetype/etc and renders pixel perfect as you could expect. right now I'm doing the same sort of polyfill for canvas.measureText. See here as well for other like minded people |
Using custom fonts, special characters like the german umlaute might have the wrong size values. See http://jsfiddle.net/tQCTd/9/ The top border is right in the middle of the dots on top of the characters. This worked in Version 1.4.13. |
I've gotten a general shim to work with openType.js and fabric (both nodeJS and browser). This relies on having a "Font.js" file that is able to resolve a openType font definition given the family name of the font. This allows full rendering (however, edit mode may be crippled). This gives pixel perfect rendering of fonts of any type (japanese, kerned, etc). // override filltext so we get best rendering of fonts via opentype
$scope.canvas.fillText = $scope.canvas.contextContainer.fillText = function(text, top, left) {
var font = Font.resolve($scope.canvas.contextContainer.font);
var path = font.getPath(text, top, left, font.size);
path.fill = $scope.canvas.contextContainer.fillStyle;
path.draw($scope.canvas.contextContainer);
};
$scope.canvas.measureText = $scope.canvas.contextContainer.measureText = function(text, size) {
var font = Font.resolve($scope.canvas.contextContainer.font);
return font.measureText(text, size);
}; The font.js is a relatively simple class - simply using OpenType to resolve the TTF/OTF and giving it a hash lookup. From node we simply walk a directory and preload all the fonts into a hash. For browser we resolve the first time and then cache in one area. In others we use google font loader. var Font = {
resolve: function(name) {
// .. find the font using your own repo/lookup
// opentype.load('fonts/' + name + '.ttf', function(err, font) {
// if (err) throw err;
// cache[name] = font;
// });
return cache[name];
}
} |
Hi, I need below value after rotation :
can anybody help to me to get all values by small code or any function which work smoothly ? Please find attachment what exactly i need. Thanks, |
@mukeshcp i'll be taking a look at this over the next month. But after exploring the canvas code for line breaks another issue is in the words as well. https://en.wikipedia.org/wiki/Line_breaking_rules_in_East_Asian_languages Specifically the _wrapLine(...) call inside iText assumes that the words being wrapped are english written system so that if I typed in japanese it would not take into account word wrapping rules here. For example:
There are no white-space characters for this. http://www.localizingjapan.com/blog/2012/01/20/regular-expressions-for-japanese-text/ Verification that custom fonts in the browser render their line breaks and font kerning exactly as they do in node (using opentype shim). Its a bit ugly on the node side as I can't seem to override The main change to fabric is below - note in the _wrapLine(..) function replacement we dont do it by character (char[0].width + char[1].width + char[2].width) as that destroys kerning information http://type.method.ac/. Specifically "AVAVAVAVAV" becomes invalid as measuring "A" by itself and "V" by itself doesnt take into account kerning... So we need to measure as we build a buffer. The bad in this is that the assumption on when we effectively can take a break, the marker is currently based on a very very basic english written system (and was before), checking for spaces to determine "hey maybe we can break here" and then proceeds to measure the next collection of characters, if we overflow the box, we break back to the last candidate line breakpoint. This needs to be extended with other language break options (probably allowing custom injection of break 'rules') by an external party? Such as
update Japanese text word wrapping... I think it's best to allow an external party to inject their word wrapping rules and detection as this can get nasty... Note in the below we avoid wrapping on the punctuation as that is not allowed in japanese... |
@terrancesnyder I tried your method and it works fine but the problem is how can I define styles like bold and italic? I really need some guidelines here so any help would be appreciated |
@terrancesnyder another issue, I have var fabric = require('fabric'); I tried this but not calling my own function var orig_drawImage = snapshotCanvas.contextContainer.fillText;
|
@fahadnabbasi bold and italic are usually the names of the fonts themselves - you might have two different TTFs |
@terrancesnyder thanks now I understand the whole concept and implemented it without any problem :) |
it's possible iText can rendering text use writing-mode: tb-rl css style? |
The issue is resolved for me using a shim that overrides the canvas functions I currently got this working by loading the shim
... and then applying it to the native canvas
And you can then you can wrap that |
even if speed wouldn't be great, would be an option for many cases. Also fabric generally |
Hello, i'm doing a toDataURL to generate png from text, and text was cropped, i didn't find a real solution, what i've done is a |
Hi, we are using custom fonts on node.js, it seems that when using custom fonts the width returned by textItem.width and textItem.height do not match what is actually rendered. It works fine with the default font.
Here is some sample code bits:
var font1 = new canvas.Font('Symbola605', '/fonts/truetype/ttf-ancient-scripts/Symbola605.ttf');
canvas.contextContainer.addFont(font1);
var text = new fabric.Text("testing 123" , {
fontSize: 45
,textAlign: 'center'
,fontFamily: 'Symbola605'
,backgroundColor:'silver'
});
console.log(">>>>>>>>> " + text.width + " X " + text.height + " <<<<<<<<<");
The log does not match the actual width of the text when measured after being rendered in the png.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: