Prev: Rearrange equation
Next: BinLists in Array
From: John Fultz on 9 Aug 2010 05:13 This is why we have an Automatic value as an option for Antialiasing. In some cases, antialiasing clearly contributes to image quality, and in some cases, it clearly degrades it. Automatic ties into an algorithm which attempts to efficiently make determinations about what would look best. Because it tries to do so efficiently, there are cases where it doesn't do an absolutely perfect job. Also, something I'd like to clarify from your message....the Antialiasing option does not affect 3D graphics, and that 3D graphics cannot have antialiasing turned on and off at the level of individual primitives. This is because 3D acceleration hardware doesn't support control of antialiasing at that fine of granularity. Because of the fundamental differences in the way things work for 3D, 3D antialiasing is controlled by a different option (RenderingOptions->"HardwareAntialiasingQuality"). It's more easily controlled in the Appearance->Graphics pane of the Preferences dialog. Sincerely, John Fultz jfultz(a)wolfram.com User Interface Group Wolfram Research, Inc. David Park wrote: > One can control whether fractions change their script size and other > features with the FractionBoxOptions. > > fraction = Style[(a + b)/c, > FractionBoxOptions -> {AllowScriptLevelChange -> False}]; > > Then to write a Text cell with the fraction: > 1) Write the text and leave a place for the Inline cell. > 2) Put fraction into the Inline cell and evaluate in place. > > You can also control text format with the LineIndent and LineSpacing > options. > > Presentations used to have an Antialiasing command, but now that Version 6 > introduced it as the default standard the shoe is on the other foot and it > has an Aliasing command! Many users might not be aware that Antialiasing can > be turned on and off, not just for an entire graphic but also for individual > primitives. If you are drawing horizontal or vertical lines then > Antialiasing will often cause them to be slightly fuzzy and thick depending > on their exact placement on the screen. By turning Antialiasing off for > these particular lines you can sharpen them up. You will notice that WRI > does not use Antialiasing on Frames and Ticks. > > > David Park > djmpark(a)comcast.net > http://home.comcast.net/~djmpark/ > > > > From: Murray Eisenberg [mailto:murray(a)math.umass.edu] > > First, one can never tell ahead of time what might emerge in a > subsequent version! > > Second, as to size of typeset fractions: the often unpleasant small size > is akin to the default behavior the "gold standard" of mathematical > typesetting, namely, LaTeX. There the size of fractions in in-line math > automatically shrinks, but if you want to resize it larger, you can > explicitly do so by inserting a markup command to say to use display > style, which sets numerator and denominator in normal size -- with the > result, of course, that the line with such an in-line fraction becomes > higher than normal and extra inter-line leading has to be introduced > (automatically), which can lead to unpleasant results. > > (So what mechanism would you want to control fraction size, and how > would you want the inter-line spacing to be handled. (AFAIK, Mathematica > does not a distinction between typesetting in-line math and display math.) > > Third, as to indicating where an error is: perhaps part of the > difficulty here the very syntax of Mathematica. Syntactical scanning of > an expression is not such a simple thing. Here I contrast with J or APL, > where there is a fairly strict left-to-right or right-to-left > syntactical scanning, so that it is essentially trivial to determine > where an error occurs. > > On 8/6/2010 6:56 AM, S. B. Gray wrote: >> This was posted in 2003: >> >> "Selwyn Hollis"<selwynh(a)earthlink.net> wrote in message >> news:bgcupq$9qi$1(a)smc.vnet.net... >> > > Print preview should certainly be near the top of any wish list. > (But >> > > if you're fortunate enough to have a Mac w/OS X, printing to PDF > is >> > > almost as good.) >> > > >> > > To any such wish list I'd also add, in no particular order: >> > > >> > > * antialiasing of graphics!! >> > > * flexible top/bottom cell margins >> > > * serious undo functionality >> > > * real unicode support (on the Mac anyway) >> > > * better find/replace (e.g., replace all in selection) >> > > * robust import of eps and pdf graphics >> > > * less need for tweaking to make expressions look right; namely: >> > > ** better typesetting of fractions (size should not be > connected >> > > to sub/superscript multiplier) >> > >** more consistent and reliable placement of sub/superscripts >> > >** more consistent and reliable spacing >> > >** more consistent and reliable sizing of summation and integral > signs >> To which I would add: >> >> 1. Make word wrap work in a rational way. At present, it sucks. >> 2. Allow noncontiguous selection of text like MS Word (finally) does >> 3. Get a text menu displayed, again like MS Word >> 4. Allow making actual margins around graphics variable >> 5. Make the cell properties more visible (the stripes on the right edge) >> 6. MAKE THE FOUND OBJECT HIGHLIGHT MORE VISIBLE (when you do search) >> 7. MAKE THE ERROR MESSAGES USEFUL(Mathematica knows where the error is; > why >> doesn't it tell you?) >> >> 8. Give some indication that Wolfram listens to its customers. >> 9. I expect a certain number of these suggestions and Hollis' to be >> acted on, namely zero. >> >> Steve Gray >> >
From: Helen Read on 10 Aug 2010 03:57 On 8/9/2010 5:12 AM, Murray Eisenberg wrote: > Yes, that works. But it seems unnecessarily indirect. When I'm typing a > text cell, I hate to interrupt the flow of thought by going to a > different cell to create the fraction, then put it into the text cell. > > What might be better is a Format menu entry for changing the fraction > size change. > > Actually, the problem is even worse than fractions: integral signs, > summation signs, etc., whose height one should be able to change easily > (without the kludge of selecting the characters and specifying a > different point size -- which then gets messed-up when you print or > change to a different screen environment, such as Presentation). I habitually select the fraction or integral or whatever (Ctl-. is helpful for selecting), then Alt-+ once or twice to enlarge it. I do this so often I don't even think about it. It's all keyboard shortcuts, and does not interrupt the flow of typing in a text cell. -- Helen Read University of Vermont
From: Fred Klingener on 10 Aug 2010 03:58 On Aug 9, 5:13 am, "Carl K. Woll" <ca...(a)wolfram.com> wrote: > On 8/8/2010 6:22 AM, Fred Klingener wrote: > .... > > I'd love to figure out how to make Hyphenation use hyphens. There used > > to be options to set this, but AFAICT they went away, I don't know > > when. If they are still there, I can't find them in the docs and can't > > find them with exhaustive trial. .... > Here's an example that turns on hyphenation: > > TextCell[ExampleData[{"Text", "USConstitution"}], > TextJustification -> 1, Hyphenation -> True, > HyphenationOptions -> {"HyphenationCharacter" -> "\[Hyphen]"}] Carl, Thanks for the example. I'll lead with the good news that that works. But then I have to list some associated problems: On my system (Mac Intel Core Duo, OSX 10.6.4, Mathematica 7.0.1.0) 1.) The doc center returns nothing for 'HyphenationOptions' 2.) Options[TextCell]//TableForm gets me a list that doesn't include HyphenationOptions. 3.) Options[TextCell, HyphenationOptions] gets me a 'Options::optnf: HyphenationOptions is not a known option for TextCell. >>' 4.) Copying and pasting your example gets me a cell with the 'HyphenationOptions' redded out, reflecting my System preferences for non-conforming syntax . Oddly, the 'HyphenationOptions' in item 3.) above is properly black. 5.) Executing the cell gets what appears to be a properly justified, hyphenated-with-hyphens document. my So even if I had been able to remember or dig up the old form, I probably wouldn't have even tried to execute the redded-out line, such is my faith in Wolfram and Mathematica. It can't be called a 'bug' if the system successfully performs a task it doesn't promise to do, but maybe it's a problem that could be fixed. Thanks, Fred Klingener > > indentation, justification, hyphenation, etc. when I'm led by other > > considerations to nest Styles, TextCells, Panes or Panels and other > > elements. A lot of the inheritance rules I imagine would apply don't. > > > I'd love to see a more tolerant Google-like doc search facility. > > > Thanks for listening, > > Fred Klingener
From: Murray Eisenberg on 11 Aug 2010 04:46 Using the Alt+ shortcut is already an expedient I'm reduced to using at times. Unfortunately, that gives the selected text a fixed font size. And although that will automatically scale if you magnify the document, it fails if you use a different environment. For example, if you switch to Presentation environment, now what was magnified can actually become smaller than the surrounding text! What's needed is a user-friendly means of specifying ratios of magnification rather than fixed-size magnification. On 8/10/2010 3:56 AM, Helen Read wrote: > On 8/9/2010 5:12 AM, Murray Eisenberg wrote: >> Yes, that works. But it seems unnecessarily indirect. When I'm typing a >> text cell, I hate to interrupt the flow of thought by going to a >> different cell to create the fraction, then put it into the text cell. >> >> What might be better is a Format menu entry for changing the fraction >> size change. >> >> Actually, the problem is even worse than fractions: integral signs, >> summation signs, etc., whose height one should be able to change easily >> (without the kludge of selecting the characters and specifying a >> different point size -- which then gets messed-up when you print or >> change to a different screen environment, such as Presentation). > > I habitually select the fraction or integral or whatever (Ctl-. is > helpful for selecting), then Alt-+ once or twice to enlarge it. I do > this so often I don't even think about it. It's all keyboard shortcuts, > and does not interrupt the flow of typing in a text cell. > -- Murray Eisenberg murray(a)math.umass.edu Mathematics & Statistics Dept. Lederle Graduate Research Tower phone 413 549-1020 (H) University of Massachusetts 413 545-2859 (W) 710 North Pleasant Street fax 413 545-1801 Amherst, MA 01003-9305
From: telefunkenvf14 on 11 Aug 2010 04:45
On Aug 10, 2:58 am, Fred Klingener <gigabitbuc...(a)BrockEng.com> wrote: > On Aug 9, 5:13 am, "Carl K. Woll" <ca...(a)wolfram.com> wrote: > > > On 8/8/2010 6:22 AM, Fred Klingener wrote: > > ... > > > I'd love to figure out how to make Hyphenation use hyphens. There use= d > > > to be options to set this, but AFAICT they went away, I don't know > > > when. If they are still there, I can't find them in the docs and can'= t > > > find them with exhaustive trial. > ... > > Here's an example that turns on hyphenation: > > > TextCell[ExampleData[{"Text", "USConstitution"}], > > TextJustification -> 1, Hyphenation -> True, > > HyphenationOptions -> {"HyphenationCharacter" -> "\[Hyphen]"}] > > Carl, > > Thanks for the example. I'll lead with the good news that that works. > But then I have to list some associated problems: > > On my system (Mac Intel Core Duo, OSX 10.6.4, Mathematica 7.0.1.0) > > 1.) The doc center returns nothing for 'HyphenationOptions' > > 2.) Options[TextCell]//TableForm gets me a list that doesn't include > HyphenationOptions. > > 3.) Options[TextCell, HyphenationOptions] gets me a 'Options::optnf: > HyphenationOptions is not a known option for TextCell. >>' > > 4.) Copying and pasting your example gets me a cell with the > 'HyphenationOptions' redded out, reflecting my System preferences for > non-conforming syntax . Oddly, the 'HyphenationOptions' in item 3.) > above is properly black. > > 5.) Executing the cell gets what appears to be a properly justified, > hyphenated-with-hyphens document. > my > So even if I had been able to remember or dig up the old form, I > probably wouldn't have even tried to execute the redded-out line, such > is my faith in Wolfram and Mathematica. > > It can't be called a 'bug' if the system successfully performs a task > it doesn't promise to do, but maybe it's a problem that could be > fixed. > > Thanks, > Fred Klingener > > > > indentation, justification, hyphenation, etc. when I'm led by other > > > considerations to nest Styles, TextCells, Panes or Panels and other > > > elements. A lot of the inheritance rules I imagine would apply don't. > > > > I'd love to see a more tolerant Google-like doc search facility. > > > > Thanks for listening, > > > Fred Klingener Given the talk about interrupting the writing flow, here's something really I wish worked: Windows Speech Recognition (and Dragon Naturally Speaking, for that matter.) This is really the only reason I ever use MS Word instead of LyX or Mathematica. While we're on the "text services framework" (I believe that's one way to build these features into Windowz apps), I have a tablet PC and have tinkered with the handwritten input. I didn't find it very useful, which is probably Microsoft's fault. Ideally it would be possible to have better bindings to the types of symbols Mathematica uses, so I could handwrite code. As is, the math input panel expects "correctly formed" mathematical equations. Trying to feed it anything else is an exercise in futility. From what I've read, this could, in theory, be accomplished with a custom dictionary, although I've never actually seen how to create one. -RG |