Feature: Line height attribute

[CatHood0]

Is there an existing issue for this?

• [X] I have searched the existing issues

Proposal

I propose creating an attribute to be able to modify the space between lines, of course, I am not just proposing whether to do my part. I already have the implementation done with the button next to the attribute, however, I would like to know if there are plans to implement this feature, since I have seen several ones (like me) that for their applications, an attribute like line-height , it would be very good for us, since it makes the editor more complete (and the spice between words and letters is another story.

The issue is that, if it is planned, I would like to know where I could start looking to add it natively to the project.

This is how work by now:

https://github.com/singerdmx/flutter-quill/assets/114286961/927836e4-5c6c-4835-8124-90d4aac911fe

[singerdmx]

I wonder how this is handled in react-quill

[singerdmx]

Below is the reply from ChatGPT:

React Quill does not have a built-in attribute specifically for setting line height directly through its API. Instead, you can adjust line height and other styles by applying custom CSS to the editor content.

Here’s how you can adjust line heights in React Quill:

1. Define your CSS for the desired line height, for example:

.ql-editor {
  line-height: 1.5;  /* Adjust the value as needed */
}

2. Ensure this CSS is loaded into the component where React Quill is used. This could be in your global stylesheet or scoped styles depending on your setup.

[singerdmx]

If we cannot find this being enabled elsewhere, we may have to create a new attribute with a good name

[CatHood0]

Here’s how you can adjust line heights in React Quill

I saw this before. I searched, but found a same answer as your. Then i decide just create a custom attribute that isn't at react-quill. I don't know what do you think about it. Should we add it since react-quill doesn't use it?.

On my implementation i called as:

class LineHeightAttribute extends Attribute<String?> {
  const LineHeightAttribute({String? value = "1.0"})
      : super(
          'line-height',
          AttributeScope.block,
          value,
        );
}

[singerdmx]

What would the corresponding delta json look like?

[CatHood0]

Looks like:

[singerdmx]

I am fine with line-height But would the number mean differently for different platform such as web v.s. mobile?

[singerdmx]

Here is what ChatGPT says:

it is a multiplier applied to the current font size to determine the height of the line boxes in which the text is placed. Here’s what that number represents:

• Unitless value (e.g., 1.5): This is a multiplier applied to the element’s font size. For example, if the font size is 16px, a line-height of 1.5 means the actual line height will be 24px (1.5 times 16). This is the preferred method because it maintains the line height proportional to the font size, making it easier to manage across different font sizes and on responsive designs.
• Percentage value (e.g., 150%): This also acts as a multiplier but is based directly on the percentage of the font size. Like the unitless value, 150% of a 16px font size results in a 24px line height. The effect is similar to using a unitless value, but it’s explicitly tied to a percentage.
• Length value (e.g., 20px): This sets the line height to a fixed value, regardless of the font size. This can be useful for achieving specific spacing effects but is less flexible when dealing with varying text sizes or responsive layouts.

[singerdmx]

So we will only support Unitless value for now?

[CatHood0]

I think on this feature using always Unitless (because i'm make this one using as a base LibreOffice, Word, and others Word Processors), but, idk about web platform. I'll need to take a look to watch the behavior. Any suggestion?

[singerdmx]

Just unitless value should be fine. I just want you to be aware the existence of the other two.

[singerdmx]

Actually try not to make this overcomplicated and only supporting unitless value should be good

[CatHood0]

I know, i think this works better using unitless because is easy to maintain, instead calculating percentage or the length value. I'll do the pr soon