I am displaying a word cloud of comma separated values using React Vega. Font size range used in the spec is "fontSizeRange": [30,200]. However sometimes the text crosses the boundaries of the chart area and its font-size becomes 0. Hence it does not render in the cloud. This occurs randomly, but is not an expected behaviour as it displays empty cloud despite having single phrase data. The problem is solved when I reduce the font size, let's say to [30,60]. However with such a smaller range, when number of phrases is huge, all the phrases appear to have same font-size nearly. How to handle these scenarios, is there a way we can display the phrases all the time (font size should never become 0) ?
I have shared my spec in the below URL. After reloading the editor 5-6 times, please observe that sometimes the text is visible in the cloud, while sometimes it's not.
Link of spec in Vega editor
Related
I have a variable-width container (screen width) and fixed left and right margins. Remaining area gives me a constraint for maximum text width, where I'm placing text of variable content (multiple languages). I want text to fit into that width without truncation, wrapping if needed. Text is relatively short - it may fit into single line, likely to fit into 2 lines and will fit into 3 lines for sure.
I want to avoid cases like (2) - where text wraps into long and a short line. It does not look nice. Instead I would like it to wrap more evenly, like in case (3).
For the demo purposes I've hardcoded hand-picked margins, but I want solution to work automatically for any text content and any container width.
Is it achievable using built-in Flutter widgets, or I need to implement something custom, similar to https://pub.dartlang.org/packages/auto_size_text?
I would like to generate some diagram style graphics using SVG and use text in the diagrams. My problem is, how to know the size of the text in advance to be able to adjust the rest of the layout accordingly. To make this explicit: I'm not talking about SVG in a browser. I would like to work with fixed units and generate PDF for printing for example. So if I use a 12pt font, it should also be printed as 12pt font.
To have a more concrete example: Lets assume I have the three strings "bla", "blablub" and "blubblablub". I would like to print them in a given 12pt font, determine the string size and enclosing boxes and draw the biggest sized box around all of them. The idea is to have equally sized boxed around all, based on the longest text.
Could somebody give me a hint how to do that or why it is not possible? Searching for this topic, I only get some JavaScript tricks in the browser, which usually involves rendering the text and then re-rendering everything again.
Using HitTestTextPosition style API from IDWriteTextLayout I did not managed to handle properly text positions inside "ti", "ffi" or other ligatures with fonts like Calibri. It always returns position after or before ligature not inside like t|i or f|f|i.
What is the recommended way to do a caret movement inside ligatures with DirectWrite API?
There... is no "inside" position if you have GSUB replacements turned on?
Opentype GSUB ligatures are single glyph replacements for codepoint sequences, rather than being "several glyphs, smushed together". They are literally distinct, single glyphs, with single bounding boxes, and a single left and right side bearing for cursor placement/alignment. If you have the text A + E and the font has a ligature replacement that turns it into Ӕ then with ligatures enabled there really are only two cursor positions in that code sequence: |Ӕ and Ӕ|. You can't place the cursor "in the middle", because there is no "middle"; it's a single, atomic, indivisible element.
The same goes for f. ligatures like ff, fi, fl, ffi, ffl, or ſt: these are single glyphs once shaped with GSUB turned on. This is in fact what's supposed to happen: having GSUB ligatures enabled means you expressly want text to be presented—for all intents and purposes—as having atomic glyphs for many-to-one substitutions, like turning the full phrase "صلى الله عليه وعلى آله وسلم", as well as variations of that, into the single glyph ﷺ.
If you want to work with the base codepoint sequences (so that if you have a text with f + f + i it doesn't turn that into ffi) you will need to load the font with the liga OpenType feature disabled.
The text editors I know of use the simple hack of (1) dividing the width of the glyph cluster by the number of code points within the cluster (excluding any zero width combining marks), rather than use the GDEF caret positioning information. This includes even Word, which you can tell if you look closely enough below. It's not precise, but since it's simple and close enough at ordinary reading sizes, it's what many do:
(2) I've heard that some may (but don't know which) also use the original glyph advances of the unshaped characters (pre-ligation) and scale them proportionally to the ligature cluster width.
(3) Some text editors may use the GDEF table, but I never knew of any for sure (possibly Adobe In-Design?).
The most challenging aspect of using methods 2 or 3 with IDWriteTextLayout is that accessing the corresponding IDWriteFontFace in that run requires quite the indirection because the specific IDWriteFontFace used (after resolving font family name+WWS+variable font axes) is stored in the layout but not publicly accessible via any "getter" API. The only way you can extract them is by "drawing" the glyph runs via IDWriteTextLayout::Draw into a user-defined IDWriteTextRenderer interface to record all the DWRITE_GLYPH_RUN::fontFace's. Then you could call IDWriteFontFace::GetDesignGlyphAdvances on the code points or IDWriteFontFace::TryGetFontTable to read the OpenType GDEF table (which is complex to read). It's a lot of work, and that's because...
The official PadWrite example has the same issue
IDWriteTextLayout was designed for displaying text rather than editing it. It has some functionality for hit-testing which is useful if you want to display an underlined link in a paragraph and test for it being clicked (in which case the ligature would be whole anyway within a word), or if you want to draw some decorations around some text, but it wasn't really intended for the full editing experience, which includes caret navigation. It was always intended that actual text editing engines (e.g. those used in Word, PowerPoint, OpenOffice, ...) would call the lower level API's, which they do.
The PadWrite sample I wrote is a little misleading because although it supports basic editing, that was just so you can play around with the formatting and see how things worked. It had a long way to go before it could really be an interactive editor. For one (the big one), it completely recreated the IDWriteTextLayout each edit, which is why the sample only presented a few paragraphs of text, because a full editor with several pages of text would want to incrementally update the text. I don't work on that team anymore, but I've thought of creating a DWrite helper library on GitHub to fill in some hindsight gaps, and if I ever did, I'd probably just ... use method 1 :b.
I'm trying to process an image using ABBYY OCR SDK using the sample code placed in this question but I'm not able get the co-ordinates right for a specific word say "OCR" on the screenshot below.
I want to draw an overlay (yellow rectangle over the word "OCR") and sometimes the rectangle is placed very far away from the actual word.
The XML you get is synthesised according to this schema.
For each recognized character it will contain an instance of charParams element as shown in the answer you linked to. The element will contain the coordinates in page pixels - the same XML also contains a page element:
<page width="..." height="..." resolution="..." originalCoords="...">
where the image width and height are stored. So l and r for each charParams element is in range 0..width-1 of the corresponding page and t and b for each charParams element is in range 0..height-1 of the corresponding page.
Also it's worth mentioning explicitly that all coordinates are in pixels - they are completely resolution-agnostic. This is why whenever you try to highlight anything on an image you have to take zoom into account - the image will likely not be always displayed as is by your device software, but will be downscaled and so you have to map page coordinates onto your zoomed-out image coordinates and highlight appropriately.
Have you checked the DPI of the original image and also check the documentation to make sure the OCR engine is using the same DPI and not returning the image in points or some other measurement system.
It could be that rectangle you are drawing in iOS is not based on pixels but on some other measurement system also.
You just need to work through the process, testing as you go, and work out where the problem is coming from. It is most likely a uniform scaling and the distance from the actual word is proportional to the distance of the word from the top left of the page.
I draw some text on screen using ID3DXFont::DrawText. This text should be displayed the same regardless of screen resolution.
For example, if screen resolution is low, text wrapped and when it is higher text is not wrapped. How can I avoid such situation? I want text size to be connected to screen resolution so if resolution is lower I want the text to be relatively smaller so that no wrapping happens. Is there any way?
Thanks in advance
Below is a logical solution. It doesn't have any of the code or procedures needed to make work in direct X but having done something similar outside of DirectX I wanted to share the logic
Working on whatever default screen resolution you want set the font to be the size needed.
Find the percentage of the screen height the font size you chose takes up.
Then having stored that value when you go to render again, in the final version of the program, calculate the font size based on the screen size and the percentage
What I was working in had functions like GetTextHeight and properties on the font size to allow you to set the height (which in turn set the font size appropriately). So if can find anything similar to this in DirectX than this could be a route for you to take.