Thinner blinking "caret/sursor" while editing text

[Noob]

The blinking "caret/cursor" while editing text is quite thick ( 3 or 4px ) compared to the default OS X caret, which is usually about 1px thick. This makes editing large bodies of text, especially smaller-sized, very cumbersome and difficult at times. Perhaps a "standard" thickness for the caret/cursor could be implemented in future versions of Designer/Photo?

[osang]

+1

[Noob]

Additionally, the caret (which is black) has a slice of white on the right side. Assuming this is for when text is on a dark background so the caret is still visible—maybe not—but in any case it feels very clunky. Perhaps the entire caret inverses color in that case, eliminating the need for the thicker / two-colored caret, as it is now.

[Dave Harris]

OK, I've halved the width of the caret. Unfortunately there's not much we can do about the white edge. As you thought, it's to ensure the caret is visible against dark backgrounds. At the point it gets drawn, we can't make it invert the colours behind it because those colours aren't known.

[Noob]

@Dave sounds great, thanks!

 

One other thing about the caret is the height. Currently, the height of the caret extends far beyond the top of the text bounding-box, especially with the artistic text tool. How about having it cut off/stop at the top?

 

And, out of curiosity is the new caret basically half black, half white — each one pixel wide?

 

cheers

[Dave Harris]

The height of the caret is the height of the text (including the area for accents etc). Why is it a problem if it goes outside the text box?

 

On a non-retina display the old caret was 2 pixels wide, with a half-pixel white shadow. It's now 1 pixel wide, with the same shadow. On a retina display OS X will scale it up to double those values.

[Noob]

@dave harris

 

>>The height of the caret is the height of the text (including the area for accents etc). Why is it a problem if it goes outside the text box?

 

Correct. The problem is actually the text box, not the caret. The top of text box should include the accents, but they rest outside. If the top of the text box matched the accent height, it would also match the caret height, thus fixing the problem. This is a major issue for baseline grids and snapping.

 

For example, if you set the font size to 16px with line-height 24px on an 8px baseline grid, the text should rest perfectly on the horizontal grid line. However, currently, the text baseline rests slightly above the horizontal grid line. Because the text box does not include the accents, it breaks the vertical rhythm.

 

I've tested with multiple fonts, so that's not the issue. The solution is to extend the text box frame up, to include the cap-height AND accents.

 

Reference image: https://drp.io/i/EyzYzxv0e

[Dave Harris]

We don't currently support baseline grids, but when they do, they will affect the text baselines directly, so the first baseline advance will be irrelevant.

 

I am wondering what app you are using that draws the text frame as you describe. I just checked InDesign and Illustrator, and neither includes the accent area in the text frame. InDesign has Object > Text Frame Options > Baseline Options that purports to support Ascent and Cap Height, but its Ascent does not include accents either. Illustrator doesn't have the option that I can see, and seems to always use what Indesign calls Ascent. The baseline we use seems to match Illustrator.

[Oval]

The baseline we use …

 

There is only one baseline in a font set, right?

 

@ Serif: To make work of users easier: If you already “use the baseline”, implementing it before 2017 as a snapping line could be done?

 

@ Noob: The accents have nothing to do with the baseline of a font.

[Dave Harris]

There is only one baseline in a font set, right?

 

We're talking about the advance from the top of the frame to the baseline of the first line of text. I used "baseline" as short-hand for that phrase.

 

 

@ Serif: To make work of users easier: If you already “use the baseline”, implementing it before 2017 as a snapping line could be easy enough?

 

Ben has been working on improved snapping for text. This will include a form of snapping text baselines. This is different from a proper baseline grid, which we will also do.

[Oval]

Ben has been working on improved snapping for text. This will include a form of snapping text baselines.

 

Great to read/hear! Are those improvements completed with and integrated in the 1.5 Beta?

 

(((We never dreamed of a baseline grid in AD. That would be awesome.)))

 

 

 

 

We're talking about the advance from the top of the frame to the baseline of the first line of text. I used "baseline" as short-hand for that phrase.

 

Thank you so much and sorry, it is not easy to follow foreign technical terms that are used for something totally different.

[Dave Harris]

I don't know if creating baseline grids will make it into Designer or Photo. They will be able to edit Publisher documents that have baseline grids.

[Noob]

@Davi Harris

 

>> I am wondering what app you are using that draws the text frame as you describe

 

Sketch app renders the text frame as such. This mimics the way line-height and text work on the web.

 

Below is a screenshot of how Sketch renders 16px text with line-height 24px on an 8px baseline grid:

 

https://drp.io/i/NkND25DAl

[Noob]

And, while we're on the topic of text, I think the "Frame Text" box should have the option to set auto height, so the bounding-box is only as tall as the text within. I posted a feature request with more info here:

 

https://forum.affinity.serif.com/index.php?/topic/19369-auto-height-for-frame-text/