While creating a math test on my site, I ran into an issue: An inline multi-line expression (equation), horizontally aligned at the equal signs, will be vertically centered on its row.
If the expression only takes up a single row, it works perfectly (even though I must use different fonts and sizes for the site and MathJax).
Is it possible to add a command (something like \valign) to the expression so that the row that contains the command becomes the one that is vertically aligned with the surrounding text?
For example:
\(\begin{align}2 \cdot x &= 8\\x &=\end{align}\)
… would be …
\(\begin{align}\valign 2 \cdot x &= 8\\x &=\end{align}\)
This is how it is now:
This is how I'd like it to be:
I have tried the following:
\raise -.6em {}
This has an effect, but the value is a guess and not exact. It is still a pixel off, and the larger I make the default value (rem), the greater the error.
I have fiddled with the vertical-align of the expression and set it to text-top while leaving the surrounding text at baseline. This is also not perfect. Sure, I can mess around with CSS until this expression looks good, but what about the next one?
The align environment is a display-level environment, and should not be used within in-line math expressions. Instead, you should use aligned, which takes an option that controls its vertical alignment. So
\(\begin{aligned}[t]2 \cdot x &= 8\\x &=\end{aligned}\)
would position the alignment so that its top line is on the same base line as the surrounding text.
Here is an example:
<script id="MathJax-script" src="https://cdn.jsdelivr.net/npm/mathjax#3/es5/tex-svg.js"></script>
a) \(\begin{aligned}[t] 2 \cdot x &= 8\\x &= 4\end{aligned}\)
In this case, the [t] means align to the top line. You could also use [b] to align to the bottom line.
Related
This question already has answers here:
Understanding grid negative values
(2 answers)
Closed 3 years ago.
And this applies to columns as well. In the same CSS code, I sometimes see the grid-row-start and grid-row-end differing by 1, but sometimes differing by 0. And they seem to mean the same thing: span 1.
For example, this CSS code being linked specified box01 column start end of 1, 3, and for box02, a column start end of 2, 2:
.box01 {grid-area: 1 / 1 / 2 / 3;}
.box02 {grid-area: 1 / 2 / 3 / 2;}
Then why would we sometimes specify the same and sometimes differing by 1? Are they identical in every way? (is it supported by the specs?)
From the specification there is some special rules to handle some particular cases:
If the placement for a grid item contains two lines, and the start line is further end-ward than the end line, swap the two lines. If the start line is equal to the end line, remove the end line.
If the placement contains two spans, remove the one contributed by the end grid-placement property.
If the placement contains only a span for a named line, replace it with a span of 1.
Basically, if the end line is the same as the start line, it's not valid so the browser will remove the end line and it will fall to auto
Then you can read:
grid position
The grid item’s location in the grid in each axis. A grid position can be either definite (explicitly specified) or automatic (determined by auto-placement).
grid span
How many grid tracks the grid item occupies in each axis. A grid item’s grid span is always definite, defaulting to 1 in each axis if it can’t be otherwise determined for that axis.
And also
auto
The property contributes nothing to the grid item’s placement, indicating auto-placement or a default span of one. (See § 8 Placing Grid Items, above.)
So if you define grid-column:1/1 it means you defined grid-column-start = grid-column-end = 1. We remove the end and it's like you only have grid-column-start:1 and by default the span is 1 so visually you will have the same result as doing grid-column:1/2
We can say both are the same but the first one (defining the same number) will be considered as invalid and the Grid Placement Conflict Handling will make it behave as the second one which is the correct way to do.
Pay attention as this is not the same when dealing with negative values. See this related question: Understanding grid negative values
There is propably other particular cases but you should avoid using the same number because it's not logical and you will rely on the browser to correct your mistake.
I have a label in my app that displays multiline text by setting wrapMode: Text.WordWrap. Is there any way to calculate the location (x and y) of the end of the last line of text in the label given a constrained width? In other words, if my label is constrained to be 100 px width and the last line of text (out of three lines) ends two-thirds of the way over, I'd like to be able to know that the end of the last line is at 66 px and that the third line starts with a y-value of 40 (if, for example, each line is 20 px high).
My requirement is that I need to place a little icon/image exactly at the end of the last line of text.
Label doesn't appear to have any way to get this, but TextArea has the method positionToRectangle(position) which gives the exact location of any character in the text and is exactly what I needed.
I have an element that I want to increase in width as its parent decreases in width
The equation should look something like:
width:calc(150 + 500 / 100%);
But at least in Chrome it says the property is invalid whenever I try to divide by percent width.
Is this possible? (Alternatives to calc() are acceptable)
EDIT
I added spaces (didn't realize about that). Tried it with a variety of units, no luck yet.
Fiddle
<div style="width:100%;position:relative;">
<div style="width:calc(150px + (500 / 100%));position:absolute;top:0;left:0;">This one should get bigger as the page gets smaller</div>
</div>
Thought process:
Fixed width (150px) plus 500 divided by the current parent width.
So if the parent is 500px:
150 + 500/500 -> 150 + 1 = 151
Parent is 100px
150 + 500/100 -> 150 + 5 = 155
Parent is 20px
150 + 500/20 -> 150 + 100 = 250
Solution is so simple it's mind-boggling. Move the 500px into the first part and subtract the width.
width:calc(650px - 100%);
Gets wider as its parent gets narrower.
Updated fiddle
It seems like you've found your solution already, but I'll answer specifically why your original code wasn't working:
I'll start with the syntax for a product equation (when you divide) in calc():
<calc-product> = <calc-value> [ '*' <calc-value> | '/' <number> ]
The spec for the calc() property syntax is a bit more complicated than it sounds. When dividing in calc() as you're doing here, the right side must be a number. You cannot use "unit-ed" values:
Number values are denoted by <number>, and represent real numbers, possibly with a fractional component.
When written literally, a number is either an integer, or zero or more decimal digits followed by a dot (.) followed by one or more decimal digits and optionally an exponent composed of "e" or "E" and an integer. It corresponds to the production in the CSS Syntax Module. As with integers, the first character of a number may be immediately preceded by - or + to indicate the number’s sign.
That is to say, you cannot divide something by a percentage value like 100%.
calc() need spaces between the operators ( but just in + and -), but you are missing the units, which could be px, em,rem etc..., so would something like this:
width:calc(150px + (500px / 100%))
This is would be invalid because as explained by #TylerH, you can't divide by un-ed values(px, %, etc).
But if was possible, when you divide by 100% you are multiplying by 1, so basically you'll stay the same because 1 is the neutral value for multiplication, so this would be useless to do.
Hardly to know, because there isn't much to see in your question, and still invalid, but I'm guessing you are looking for something like this instead:
width:calc(150px + (100% / 500px))
Given your Edited question AFAIK you have to use JS to achieve this, unless you could provide a Fiddle.
I'm trying to make a subclass of QSlider that allows the user to insert "bookmarks" so they can remember significant locations on the slider. I've run into a problem painting the tabs on the slider - using QStyle.sliderPositionFromValue, I get a value but it is slightly inaccurate. If I'm on the left side of the slider, the tab is painted too far left, and on the right side it is painted too far right. I believe this is because QSlider.width() returns the width of the whole object, including the small offsets at the left and right. So width() might return 630 pixels, when the length of the slider itself is really 615.
This is the code I'm using to get the pixel position and draw a line across the slider.
pos = QStyle.sliderPositionFromValue(self.minimum(),self.maximum(),sliderIndex,self.width())
painter.drawLine(pos,0,pos,self.height())
I've been looking at the QT Source here starting on line 2699 and it seems like I need to be using the PixelMetric class from QStyle. I've tried using:
self.style().pixelMetric(QStyle.PM_SliderSpaceAvailable)
But that returns 0, which is clearly not the value I need.
I'd appreciate any advice.
Edit: As suggested in the comments, I changed the call to:
self.style().pixelMetric(QStyle.PM_SliderSpaceAvailable, QStyleOption(1,QStyleOption.SO_Slider),self)
This however, returns -14, which also doesn't match for the value of the offsets (I tried using self.width()-14 but the offset remains.
The problem I'm trying to solve is the following:
In a 2-D space, Given a grid size and a rectangle, calculate the grid cells
occupied (partially or totally) by the rectangle.
By "Grid size" I mean something like: "A 16x16 grid" or "A 32x32 grid". All grids are centered on the origin of coordinates (0,0).
The rectangle is defined by 4 floats: the left, top, width and height.
The result of this operation is always a rectangle. I'd like to return the coordinates of top-left cell (i.e. 0,0) followed by the number of cells the retangle occupies to the right and down (a bit like width and height, but for cells)
So far I've been able to write an algorithm that mostly works. What it does first, is calculating the cell coordinates where a single dot resides in the grid. Then, given the rectangle, I calculate where its top-left and lower-rights corner are on the grid, and then it's a simple substraction:
-- given a world coordinate, return the coordinates of the cell that would contain it
local function _toGrid(wx, wy)
return math.floor(wx / __cellSize), math.floor(wy / __cellSize)
end
-- given a box in world coordinates, return a box in grid coordinates that contains it
-- returns the x,y coordinates of the top-left cell, the number of cells to the right and the number of cells down.
local function _toGridBox(l, t, w, h)
local gl,gt = _toGrid(l, t) -- top left grid corner
local gr,gb = _toGrid(l+w, t+h) -- bottom-right grid corner
return gl, gt, gr-gl+1, gb-gt+1 -- return top,left,cells to the right, cells to bottom
end
Notes:
The source code is Lua, but I will accept solutions in any programming language, as long as they are intelligible.
The y-coordinate goes "down when increasing"; that's how a lot of screen systems work. I don't think that's significant for this problem, but don't get confused by that).
In a 16x16 grid, a rectangle on 0,0, with width=10 and height=20, gr will be 0 and gt 1, so _toGrid will return 0,0,1,2 (1 row, two columns, on the 0,0 cell).
The problem happens when the rectangle "touches" (not crosses) either the lower or right side of one cell from inside. In that case, _toGrid returns "one more cell" than I'd like it to.
For example, if I move the previous rectangle to the left 6 pixels (so it is on 10,0), it will be "touching" the left-side border of its containing grid, which goes from 0 to 16. Then gr will be 1, and the returned data will be 0,0,2,2.
I'd like to avoid this, if at all possible. For a rectangle going to 16 "from the left", I'd like it to remain on the first grid cell. I'd like it to begin "occupying the next cell" as soon as it surpasses 16 - for example when it's at 16.00000001 .
Also, notice that this only applies to the right and bottom sides. The left and upper sides work as I want them to. For example, a rectangle whose left coordinate is 16, should appear on the "second cell to the right", not on the first.
I'm sure the solution isn't complicated, but I've been thinking about this for a while now and I don't seem to find it. Any help will be appreciated.
For the bottom and right hand side, you need to use ceil instead of floor. I don't know any Lua, so this may not be syntactically correct, but you would want something along these lines:
local function _toGridBox(l, t, w, h)
local gl = math.floor(l / _cellSize)
local gt = math.floor(t / _cellSize)
local gr = math.ceil((l+w) / _cellSize)
local gb = math.ceil((t+h) / _cellSize)
return gl, gt, gr-gl, gb-gt -- return top,left,cells to the right, cells to bottom
end
Your problem, essentially, is that the function _toGrid is the wrong abstraction for your purpose because it always uses floor. Apparently, you locked yourself into using that abstraction, which then made it difficult to come up with the right answer.