result[i].location.set_width(run_advance - line_advance);what are you trying to do with the rectangle for this?
There are lots of different rectangles here, do you want the ink-bounds (bounds of what gets painted), (layout-bounds, close to cursor position), etc.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
result[i].location.set_width(run_advance - line_advance);what are you trying to do with the rectangle for this?
There are lots of different rectangles here, do you want the ink-bounds (bounds of what gets painted), (layout-bounds, close to cursor position), etc.
I want the boundaries of the run of text represented by the glyphs vector relative to the origin of the <textarea> in CSS pixels (converted from physical pixels), so that I can place the glyphs in the exact same position as blink does in the PDF.
This bit of the code contains a bug. I didn't fix it yet, but I think I confused myself about the callback adding multiple rows to the results vector and multiple text fragment items in the same line. The code worked as-is when I manually checked strings that change fonts on the same line, but broke in some test cases that manually added text fragments of the same font instead of setting the value. I have just uploaded some broken tests to show you what I mean.
Is there a way to get a rect directly without using the glyph advance data? In my previous CL this wasn't an issue because I wasn't dealing with any sub-line runs of text.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
result[i].location.set_width(run_advance - line_advance);April Kallmeyerwhat are you trying to do with the rectangle for this?
There are lots of different rectangles here, do you want the ink-bounds (bounds of what gets painted), (layout-bounds, close to cursor position), etc.
I want the boundaries of the run of text represented by the glyphs vector relative to the origin of the <textarea> in CSS pixels (converted from physical pixels), so that I can place the glyphs in the exact same position as blink does in the PDF.
This bit of the code contains a bug. I didn't fix it yet, but I think I confused myself about the callback adding multiple rows to the results vector and multiple text fragment items in the same line. The code worked as-is when I manually checked strings that change fonts on the same line, but broke in some test cases that manually added text fragments of the same font instead of setting the value. I have just uploaded some broken tests to show you what I mean.
Is there a way to get a rect directly without using the glyph advance data? In my previous CL this wasn't an issue because I wasn't dealing with any sub-line runs of text.
I want the boundaries of the run of text represented by the glyphs vector relative to the origin of the <textarea> in CSS pixels (converted from physical pixels), so that I can place the glyphs in the exact same position as blink does in the PDF.
Ok so you likely don't need this much complexity.
I believe you want to do something similar to:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/fonts/shaping/shape_result_bloberizer.cc;l=298-299;bpv=1;bpt=1?q=is_horizontal%20bloberizer&ss=chromium
in the callback.
Additionally you need to add to create a context object to hold the result and current offset, e.g.
```
struct {
gfx::VectorF offset;
zoom_factor; ?
std::vector<> result;
};
```
rather than just passing in the result.
The offset for the current item can be accessed via:
`rect = cursor.CurrentItem()->RectInContainerFragment();`
Then convert it to the offset you need (e.g. do you support vertical writing-modes and RTL?).
Is there a way to get a rect directly without using the glyph advance data? In my previous CL this wasn't an issue because I wasn't dealing with any sub-line runs of text.
Why do you need the rect instead of just an offset. If you are just placing glyphs then the offset should be all that you need.
You need to use the glyph advance data to do this correctly.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
I need the rectangles because when doing the coordinate transformations to place the line of text in the PDF there are axis flips and the PDF text objects refer to text by the bottom left corner while blink uses the top left corner. So I need the width and height to change the origin point.
I think I still need to use the advance info for the rectangle width because RectInContainerFragment() gives me the full width of the FragmentItem even when that FragmentItem contains multiple fonts, which I need to split into separate TextInfos because in the PDF there can only be one font per text object.
Each line of the text area (pdf text objects don't support wrapping) and each run of text with a different font needs a rectangle (a TextInfo actually).
Within the TextInfo rect I do need the offset and advance data to position the glyphs.
There are some complications with text direction when the PDF is rotated but it's currently not clear to me if I need to handle that in the callback like in your link. In general yes we're aiming to support international text.
I really appreciate your patience helping with this.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |