I wanted to show some mathematical expressions in a winforms textbox. So I thought the "Cambria Math" font would be a good choice but the text looked strange due the high top and bottom margin of the font. First I thought I made a mistake but according to this question, it's the correct behavior of the font.
Why does Cambria Math have these big margin values and how can I display my string correctly in the textbox like Word 2010?
(Note that I know only a little bit about typography ;)
Edit: I had to make the textbox that tall otherwise the caret would be invisible. The font size of the textbox is set to 8.25pt
Cambria Math uses Microsoft's mathematical OpenType extensions.
Word 2007 and later understand these and display the text with reasonable spacing.
However, notepad and Word 2000 display the text with enormous spacing, just like winforms. I guess the font has this much space by default because some characters (like U+2320, top half integral) are much larger than the alphanumerics.
If you use Cambria Math with a font engine (such as the one used by winforms) that doesn't understand the math extensions, you're going to get the big spacing.
If you're displaying simple expressions you might as well use Cambria.
Related
I need to enter a text to existing pdf (in top or bottom of the page) in c#.
I need to make sure that I dont overwrite any visible text or image.
Is there any way I could check an area in pdf if it contains text, image, control etc? I understand it will not be 100% accurate
You're going to need a full PDF consumer at the very least, because the only way to find out where the marks are on the page is to parse (and possibly render) the PDF.
There are complications which you haven't covered (possibly they have not occurred to you); what do you consider to be the area of the PDF file ? The MediaBox ? CropBox, TrimBox, ArtBox, BleedBox ? What if the PDF file contains, for example, a rectangular fill with white which covers the page ? What about a /Separation space called /White ? is that white (it generally gets rendered that way on the output) or not ? And yes, this is a widely used ink in the T-shirt printing industry amongst others.
To me the simplest solution would seem to be to use a tool which will give you the BoundingBox of marks on the page. I know the Ghostscript bbox device can do this, I imagine there are other tools which can do so. But note (for Ghostscript at least); if there are any marks in white (whatever the colour space), these are considered as marking the page and will be counted into the bbox.
The same tool ought to be able to give the size of the various Boxes in the PDF file (you'd need the pdf_info.ps program for Ghostscript to get this, currently). You can then quickly calculate which areas are unmarked.
But 'unmarked' isn't the same things as 'white'. If you want to not count areas which are painted in 'white' then the problem becomes greater. You really need to render the content and then look at each image sample in the output to see if its white or not, recording the maxima and minima of the x and y co-ordinates to determine the 'non-white' area of the page.
This is because there are complications like transfer functions, transparency blending, colour management, and image masking, any or all of which might cause an area which is marked with a non-white colour to be rendered white (a transparency SMask for example) or an area marked with white to be rendered non-white (eg a transfer function).
Your question is unclear because you haven't defined whether any of these issues are important to you, and how you want to treat them.
I've got a really simple setup - I have a string, a font and a font size on the ready. I want to render this to a Silverlight WriteableBitmap.
There's one catch - I want to be able to tell apart the letters in the rendered text. Ideally, I'd like to have a System.Windows.Rect for every rendered letter.
The problem is Silverlight's API, which is missing all of the useful stuff like Graphics.MeasureString, which I could have used to measure the letters separately.
What adequate options do I have to get the letters' measures in codebehind?
I sort of figured this out on my own. The solution is slow and far from perfect, but hey, it works!
The idea is to render the text many times, adding one letter at a time, and finding the difference between the current and previous TextBlock widths.
So, for example, if the text is "ab", we first render "a" and get its length. Then we render "ab" and find the difference, which should be the size of the rendered "b".
I'm looking for basically fastest way to display non-editable FlowDocument with continuous, variously decorated text.
I know RichTextBox and usually use FlowDowcumentScrollViewer that can display FlowDocument content.
I know TextBlock can (kind of) be fed Inlines in code, but doens't support Paragraphs etc.
But did anybody measure which of the former two are faster with different occasions (scrolling / non scrolling, long / shorter document etc.) ?
Or is there some other, more effective solution ?
Some people claim that FlowDowcumentScrollViewer is actually slower because it supports more (advanced) formatting scenarios. Not sure if thats true.
On the other hand RichTextBox has all the editing functionality etc. that drags its speed down.
As Im currently writing a RichText heavy application, I would be glad for any tips on this
The default size in pixels for a tab in a RichTextBox is apparently 48 pixels, regardless of font or font size. This is set as default by .NET without me touching the SelectionTabs array. I've checked in the RTF - there's no \tx control code or anything so where the heck is this elusive '48' number stored?
I don't want to use this as a hardcoded 'magic number' in case other systems use something other than 48 pixels for a tab.
My own purpose is to help me convert from tabs to spaces (at least for fixed width fonts). But finding an answer to this also might get us closer to controlling the tab size with a single value without setting up an 'infinite' array of tab stops as implied from this answer.
I have tried both the regular TextBox and RichTextBox in an app where I don't want any word wrap. Yes, of course I turned off word wrap in Properties. This is something that occurs at extremely long lines, like around 3000 chars or so in the RichTextBox (regular TextBox much sooner, but I can get by without it if RichTextBox works). I recognize that it is cruel and unusual punishment to subject the poor RichTextBox to such line lengths, but unavoidable. Still, it seems like abnormal behavior.
The text is just long continuous strings of repetitive ascii (genetic data), so nothing unusual there. In fact it's usually just A,C,T,G with no punctuation or spaces.
Is this known behavior?
Assuming you are using WinForms, both RichTextBox and TextBox have built-in limits for lengths of lines.
An alternative is to use a scroll viewer and manually add Labels. I do not believe there will be any limit in this scenario, although I could be wrong.
If you check Notepad (notepad.exe) in Windows, it also has a limit before it starts wrapping text, so this is standard behavior for Windows apps.
the Multiline property should be false in order for the lines not to wrap.
You could try a RichTextBox and extend the right margin to the width of the text.
richTextBox1.RightMargin = TextRenderer.MeasureText(yourString, this.richTextBox1.Font).Width;
This way you maintain the ability to have other lines.