Graphviz with fixed fontsize and maximum size - graphviz

When using dot to draw a graph, is there a way to specify the desired node label fontsize and a maximum width for the overall graph?
I tried with setting the graph size to "2.79,10000000" in order to have a image at most 2.79in wide. The default for nodes is set to a specific fontsize and a margin of "0.0,0.0".
When outputting this, dot produces a pdf that is 2.79in wide, but the fonts have been scaled down. If I correct the set fontsize by the factor my font was shrunk now, the output looks fine, i.e., my labels appear in the correct fontsize.
Is there a way to achieve the desired maximum width plus the fixed fontsize without having to manually correct the fontsize by a factor?

I don't think there is an easy general solution for this particular problem: The graph first gets layed out, then scaled down (including text) to fit the size requirement (see also Controlling the size).
If the text of a wide graph were to stay the same size when getting scaled down, in most cases the final width of the graph will probably stay almost the same.
For some simple graphs, you may specify the ratio in addition to the page size and make sure that the graph to generate will not be wider that the size (in order to prevent shrinking).

Related

handling dynamic data of large or small size in div of fixed width

I have a dynamic data (number of views(count) v/s months) as my input to my multibar graph of apexchart library.
It works nice with small data. However, when I increase the size of data, the graph looks very bad(shown in below figure). I know the reason for this. It is due to the fixed width of graph. The width of bar is calculated based on width of graph and number of data items. But then how to fix this? How to handle large and small data in a fixed sized div?
Step1 : Add a slider to the parent div of graph (overflow-x:auto).
Step2 : Increase graph width based on your data. Do not keep it fixed. Create a logic that changes width of graph (not width of div that contains graph) based on data. Even if it goes beyond the parent div, that is fine as we have added slider only to deal with this.
Step3 : Add a logic for width of bars. In apexcharts, bar width is set in percentages. So,for example : width of bar for less data = 10 (10% of graph width). width of bar for more data = 30 (30% of graph width)
So this way, even if the width of our div containing the graph is fixed, it will be able to handle dynamic data of large and small sizes.
Solution example : https://drive.google.com/file/d/1LzSNaYfzZNKQzOs8r9NVDqmQiFil-Xho/view?usp=sharing

HPDF units for text width and height

Maybe it's just my head spinning, but there seems to be no documentation on the units of measure for HPDF's HPDF_Font_TextWidth() function, nor can I figure it out.
The number I get for a particular text of 7 characters is around 3000. The rendered text seems to be around 80 pixels, which is also returned from HPDF_Page_TextWidth().
HPDF_Font_TextWidth() does not know the font size so it must use some other unit. What is it?
And is that the same unit that HPDF_Font_GetBBox() returns?
I'm actually trying to put text in the center of a rectangle, and need the width and height of the text in the units of the rectangle.
This is an old post but I just stumbled upon it because I had the same issue. As far as I know, looking into the source of HPDF_Font_GetUnicodeWidth(), the units that it returns needs to be multiplied by the font size, then divided by 1000 to get the width in points, which is what the rest of the PDF coordinate system uses.
width = (HPDF_Font_TextWidth() * font_size) / 1000.0;
All the following return EM units, which must be divided by 1000 and multiplied by the point size to get points, as stated above:
The units are relative to the baseline. Descender, BBox left & bottom are negative. The zone between caps Height and ascender is for diacritics.
To calculate the height of a slug of text, compute caps height less descender, or ascender less descender if your text has upper-case diacritics.
Keyword: Haru PDF

How to normalize screen size

I have a lot of many mobile screen standard.Example :
240x320
320x480
480x800
........
But in log i received many screen size (This screen size was detected by javascript then send to the webserver, when device access my website) :example 241x322, 239x320, 481x799 ... This size was wrong any pixel at height , weight or both of height and weight
What is the best of algorithm, or library to normalize screen size (know size 241x322 is 240x320).
You could run a simple algorithm that searches for the closest match, and change to that.
Run a loop looking for the distance (absolute value) from all heights / weights, and get the min one.
If you do them in ascending/descending order, you can break once you see the changes grow to improve efficiency.
You could also make sure the aspect radio is right as a measure of extra safety.

bounding box of n glyphs, given individual bboxes and advances

For specific reasons, I'm implementing my own font rendering, and an algorithm to compute the bounding box of a text by using bounding boxes of single glyphs, together with the respective advance, is needed. For clarification see this illustration:
For every of these N glyphs is given the relative bbox relative to the origin (xmin, xmax, ymin, ymax), and the advance (pseudocode):
int xmin[N], xmax[N], ymin[N], ymax[N], adv[N];
I will give the answer myself if noone bites.
For the general case you won't be able to accurately measure a string using just the glyph bounding box and the advance width due to hinting, kerning, and ligatures which will significantly modify the sizes of glyphs and their spacing depending on their position in the string as well as the chosen font size.
The naive way to calculate the string length by iterating the glyphs and adding the advance width and xMin will only be correct for certain fonts at certain sizes and shouldn't be used if at all possible.
The easiest way to get font metrics is to use an established font rendering engine to either directly get the length of the text (if the API exposes that) or render the text to a surface and find the min/max pixel in the X/Y directions.

Web Layouts: pixels vs percentages

What are the use cases for defining distances in a web layout for pixels and percentages?
Is there any downside to using pixels with respect to multiple resolutions? Will they scale correctly?
Percentage layout
This is generally referred to as fluid layout. Your elements will take a defined percentage of the total space available to them. This available space is determined by the element's parent.
When using percentage layouts, it's a good idea to specify a min-width and max-width on your design so that it remains usable at very low and high resolutions.
Pros
Scales with screen size, therefore get to use more space if it's available.
Cons
Makes it more difficult to know the exact position of something on screen. As a result, it can make creating precise layouts more difficult.
Can lead to unexpected layouts if child elements are fixed width (i.e. an image) and end up being larger than their fluid width parent.
Pixel layout
This is usually known as fixed layout. Your element will always be the same defined pixel size and will not take available parent space into account.
Pros
Always know an element's exact size.
Creating precise layout is easier.
Cons
You don't scale with resolutions. Your layout will always be the same width, making for wasted space when people have high resolutions.
I'll reply to this one by telling you a true story.
We had a client which wanted a map view, made up of divs.
Suddenly, he decided he wanted zooming as well.
I had to change all those fine-grained pixel positions to percentages.
Causing the wrapping div to change width/height (in pixels) relatively, we got a nice and reasonable zooming effect.
NB: During design phase, I quickly drew up a prototype, I'm going to look it up for you...
Edit: Nope, nothing found, sorry.
For percentages you have to have a base value, so it would be something like an image that has a size set outside of the CSS, if you just use a percentage on a DIV, for example, it wouldn't have anything to base that off of except the actual size it was by its being filled with text, for example, so it would not be practical to use percentages as a way to size it as it would rarely produce the desired output, if you are re-sizing something with a pixel size, such as by using javascript, you could resize by a percentage that would resize the original value (in pixels)
They do different things.
Pixel values always relate to hypothetical pixels on the output device.
Percent values relate to the computed size of the containing block (for block elements) or the containing block's font size (for font sizes).
Em and pt values relate to the current font size.
If you want your item to scale with its container, use percentages. If you want it to scale with font size, use ems. If you don't want it to scale at all, use pixels.
And then there's IE6; whoever 'implemented' CSS in that thing obviously had no idea what the various CSS properties were supposed to do.
Be careful using percentages, webkit browsers don't calculate percentages correctly. It's all because webkit doesn't calculate subpixels correct.
Detailed information about this issue can be read here: Percentage bugs in webkit
I would recommend you to always use pixels to don't have any layout dimensions differences between browsers.

Resources