Setting up my interface for a Watch glance, and the top group is getting cut off by the bottom group:
Here's how it's set up in interface builder:
I'm not sure why it's getting cut off / covered up by the other group?
You can choose the upper and lower default look of your Glance, but I do not believe you can size the upper and lower sections to be a particular size.
Look into your group's constraints: Possibly select the image, then its size in the attributes inspector. It may need to be a fixed size in order to fit the labels into the upper section.
Otherwise the outer groups will not size to fit your content, they will only size large enough to fit the default space that is given for Glances in each section.
Related
How to get the sill height (height above the floor) of a Ifcwindow in ifc file
There is no solution to get the height above the floor directly. This is because the height above for depends on several factors, like how the wall is created in which the window resides, etc.
It could be that the sillHeight is exported by the original modelling software to a custom IFC property. You could check for that, but since there is no common standard for it, it's risky.
Your best bet is to look into the ObjectPlacement property which IfcWindow inherits from IfcProduct. The ObjectPlacement defines how a product is placed either in world space or relative to its host. See https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2/HTML/schema/templates/product-local-placement.htm for details.
You need to read the ObjectPlacement property, and check if there is a RelativeTo property, if so, you need to fill into that property as well, and check if it's the placement of a floor. If so, you can stop the looping, and perform a matrix calculation on all the placements you harvested to calculate the placement of window relative to floor.
(Maybe even more simple: calculate world placement of window and floor separately, than subtract the two vector z values to get the height of window from floor)
I'm using FontForge. I'm modifying the lower case q to make a straight-stalked 9. The q has 2 logical parts, the stalk, and the 'c'. The 'c' is too big vertically. How can I scale it down vertically while keeping the vertical stroke widths the same (and not altering any of the horizontal dimensions)?
I'm a novice with FontForge, so please spell out your explanation and provide step-by-step instructions. Thanks for your help.
It sounds like you want to decrease the x-height of the 'q' without changing stroke widths.
Font-forge provides a built-in tool to achieve this: Element > Styles > Change X-Height. You might like to experiment with this, but in practice it gives you very little control over the results and I would rarely use it.
Instead I would achieve this by directly modifying the nodes of the paths.
First, I would ensure that InterpolateCPsOnMotion is enabled. Double-click the pointer tool in your toolbox to access this setting.
This will help ensure that curves scale correctly (rather than distort) as you move control points. Now, I would select the nodes at the top and sides of the bowl of the q:
and use the down arrow key to move them down about half the distance you wish to decrease the height by. Then I would deselect the nodes at the side of the bowl:
and lower the remaining nodes the rest of the distance:
You will need to check the resulting appearance and possibly make tweaks to get it perfect. Note that this or any scaling technique can subtly distort the axis of modulated strokes, which you may wish to correct.
This technique presupposes that nodes are sensibly placed at the vertical and horizontal extrema of the bowl, and that you don't have extra nodes between these extrema. If you are not in this happy situation, you can add extrema by ctrl-shift-x and you can remove surplus nodes by selecting them and ctrl-m. If you can't remove extra nodes without significantly changing the shape of the bowl, you'll just have to modify these nodes by eye.
Another point: you say you're working from a "c". I'm not sure whether you just mean the C-shape of the bowl of the q, or whether you mean you are copying the actual glyph 'c'. Note that it is rare that the bowl of a 'q' will have exactly the same shape and weight as a 'c'. Typically the stroke will be somewhat lighter to achieve the right visual grey, and especial care will be taken where it intersects the stem. Often the two shapes will differ substantially.
I haven't been able to find the answer to this question: Where in the spec or in UA documentation is the default width of a <td> defined?
I've searched the HTML Living Standard, the HTML5 Recommendation, and various other sources.
My understanding (based on usage and observation) is that a table cell will, by default, occupy the full width of the column in which it lives. And the cell cannot be given a different width than the column if other cells exist in the column.
I'm looking for official confirmation of this behavior, preferably in W3C or user agent documentation. But any authoritative reference is acceptable.
The physical/visual width of a table cell is defined not by HTML, but by CSS. The CSS 2.1 specification has an entire section dedicated to table layout that complements HTML's description of tabular data.
Furthermore, CSS itself does not fully define how the width of a cell is calculated. It does with the fixed table layout algorithm:
In the fixed table layout algorithm, the width of each column is determined as follows:
A column element with a value other than 'auto' for the 'width' property sets the width for that column.
Otherwise, a cell in the first row with a value other than 'auto' for the 'width' property determines the width for that column. If the cell spans more than one column, the width is divided over the columns.
Any remaining columns equally divide the remaining horizontal table space (minus borders or cell spacing).
The width of the table is then the greater of the value of the 'width' property for the table element and the sum of the column widths (plus cell spacing or borders). If the table is wider than the columns, the extra space should be distributed over the columns.
but it doesn't give anything beyond a rough guideline for auto table layout, which user agents are free to follow or deviate from (it lists a step-by-step procedure not unlike that of fixed table layout, but that entire list is non-normative). Generally you can expect consistent behavior from UAs in the most common scenarios — as you observe, an auto-sized table cell generally takes up as much space as required by its content, and no more. But dig into edge cases, and you'll find all sorts of crazy.
Here's the W3C standards on calculating the width of table columns. Basically it is left up to the implementing browser/agent.
If an author specifies no width information for a column, a user agent
may not be able to incrementally format the table since it must wait
for the entire column of data to arrive in order to allot an
appropriate width.
If column widths prove to be too narrow for the contents of a
particular table cell, user agents may choose to reflow the table.
Source: http://www.w3.org/TR/html401/struct/tables.html#h-11.2.4.4
Note: this is HTML4 docs.
A table cell's minimum width is 0 or the size of the largest word or image within that cell.
Table Sizing Algorithm
The default sizing algorithm requires two passes through the table data. In the first pass, word wrapping is disabled, and the user agent keeps track of the minimum and maximum width of each cell. The maximum width is given by the widest line. As word wrap has been disabled, paragraphs are treated as long lines unless broken by elements. The minimum width is given by the widest word or image etc. taking into account leading indents and list bullets etc. In other words, if you were to format the cell's content in a window of its own, determine the minimum width you could make the window before things begin to be clipped.
The minimum and maximum cell widths are then used to determine the corresponding minimum and maximum widths for the columns. These in turn, are used to find the minimum and maximum width for the table. Note that cells can contain nested tables, but this doesn't complicate the code significantly. The next step is to assign column widths according to the current window size (more accurately - the width between the left and right margins).
The table borders and intercell margins need to be included in the assignment step. There are three cases:
The minimum table width is equal to or wider than the available space. In this case, assign the minimum widths and allow the user to scroll horizontally. For conversion to braille, it will be necessary to replace the cells by references to notes containing their full content. By convention these appear before the table.
The maximum table width fits within the available space. In this case, set the columns to their maximum widths.
The maximum width of the table is greater than the available space, but the minimum table width is smaller. In this case, find the difference between the available space and the minimum table width, lets call it W. Lets also call D the difference between maximum and minimum width of the table.
For each column, let d be the the difference between maximum and minimum width of that column. Now set the column's width to the minimum width plus d times W over D. This makes columns with lots of text wider than columns with smaller amounts.
This assignment step is then repeated for nested tables. In this case, the width of the enclosing table's cell plays the role of the current window size in the above description. This process is repeated recursively for all nested tables.
If the COLSPEC attribute specifies the column widths explicitly, the user agent can attempt to use these values. If subsequently, one of the cells overflows its column width, the two pass mechanism may be invoked to redraw the table with more appropriate widths. If the attribute specifies relative widths, then the two pass model is always needed.
The column width assignment algorithm is then modified:
Explicit widths from the COLSPEC attribute should be used when given, provided they are greater than the minimum column width, otherwise the latter should be used.
For relative widths, the surplus space W, as defined above, is divided up between the columns appropriately, ensuring that each column is given at least its minimum width. If W is zero or negative, column widths should be increased over the minimum width to meet the relative width requirements.
If the table width is specified with the WIDTH attribute, the user agent attempts to set column widths to match. The WIDTH attribute should be disregarded if this results in columns having less than their minimum widths.
Recently I had much fun with the Laplacian Pyramid algorithm (http://persci.mit.edu/pub_pdfs/pyramid83.pdf). But one big problem is that the original paper is limited to 2^m+1*2^n+1 images. My question is: What is the best way to deal with arbitrary w*h instead? I can think of a couple of options:
Up sample the input to the next 2^m+1,2^n+1 up front
Pad even lines. How exactly? Wouldn't it shift the signal?
Shift even lines by half a sample? Wouldn't it loose half a sample?
Does anybody have experience with this? What is the most practical and efficient approach? Also any pointers to papers dealing with this would be very welcome.
One approach is to create an image with a width and height equal to the next 2^m+1,2^n+1, but instead of up-sampling the image to fill the expanded dimensions, just place it in the top-left corner and fill the empty space to the right and below with a constant value (the average value for the image is a good choice for this). Then encode in the normal way, storing the original image dimensions along with the pyramid. When decoding, decode and then crop to the original size.
This won't introduce any visual artifacts or degradation because you aren't stretching or offsetting the image in any way.
Because the empty space to the right and below the original image is a constant value, the high-pass bands at each level in the image pyramid will be all zero in this area. So if you are using a compression scheme like run length encoding to store each level this will be automatically taken care off and these areas will be compressed to almost nothing. If not then you can simply store the top-left (potentially non-zero) area of each level and then fill out the rest with zeros when decoding.
You could find the min and max x and y bounding rectangle of the non-zero values for each level and store this along with the level, cropped to include only non-zero values. The decoder could also be optimized so that areas of the image that are going to be cropped away are not actually decoded in the first place, by only processing the top-left of each level.
Here's an illustration of the technique:
Instead of just filling the lower-right area with a flat color, you could fill it with horizontally and vertically mirrored copies of the image to the right and below, and a copy mirrored in both directions to the bottom-right, like this:
This will avoid the discontinuities of the first technique, although there will be a discontinuity in dx (e.g. if the value was gradually increasing from left to right it will suddenly be decreasing). Choosing a mirror that keeps dx constant and ddx zero will avoid this second-order discontinuity by linearly extrapolating the values.
Another technique, which is similar to what some JPEG encoders do to pad out an image to a whole number of MCU blocks, is to take the last pixel value of each row and repeat it, and likewise for columns, with the bottom-right-most pixel of the image used to fill the bottom-right area:
This last technique could easily be modified to extrapolate the gradient of values or even the gradient of gradients instead of just repeating the same value for the remainder of the row or column.
I'm trying to make a force directed graph using d3.layout.force, and I need the container to be resizable - that is I'd like to be able calculate appropriate charge and linkDistance values based on the size, or have d3 do it for me in some magical way.
I've made an attempt (link: http://jsfiddle.net/VHdUe/6/) which only uses nodes. I'm setting the charge to a value that's based on the number of nodes that would fit across the radius of the circle that it tends to be shaped like.
The solution works for some middle-sized containers, but if you click resize a few times, you can see it doesn't really work for all sizes...
The only way forward I can see is using an svg scale transform, which will mess up the size of my elements unfavorable. Any other options?
PS: I have seen http://mbostock.github.com/d3/talk/20110921/bounding.html (the answer to D3 force directed layout with bounding box), but I'd rather have a gravity-based solution than a bounding box one.
In addition to charge and linkDistance, you also have gravity. If you want the graph to maintain the same relative density to the layout size, then you'll want to scale both charge and gravity. These are the main two computing forces that determine the overall size of the blob. See my force layout talk for more details.
I tried a few different versions, and this one seemed to work pretty well:
var k = Math.sqrt(nodes.length / (width * height));
layout
.charge(-10 / k)
.gravity(100 * k)
Here nodes.length / (width * height) is linearly proportional to the graph density: the area of the nodes divided by the area of the layout. The charge force follows the inverse-square law, so that might explain why the square root works well. D3's "gravity" is a virtual spring that scales linearly with distance from the layout center, so this also increases the gravity as the graph becomes denser and discourages nodes from escaping the bounding box.