I've only been able to find one or two references to the maximum allowed column we can add to a customized version of Foundation5 and these claim the number is 16. However I can find no official documentation of this.
In the Foundation 5 download customizer there are input fields for '# of Columns', 'Gutter (em)', and 'Max-Width (em)'.
I have tested with a value of up to 24 columns and the CSS output has classes included for up to 24 columns, so I'd assume the 16 column restriction no longer applies (or only applies to older versions of Foundation).
So my questions are:
Does anyone know what the max number of columns allowed is / or if others are using a particular number successfully?
If I custom download Foundation5 with more columns, how do I know what gutter width and Max-Width values will work out correctly or can I just use anything (the downloader doesn't give any indication of incorrect values or out of range values)?
Having a custom download, how would I best manage Foundation updates if I wanted to upgrade the CSS to future newer versions?
PS: Im not using SASS or other pre-processor tools.
I am afraid that the only way I can see doing this easily is by using Sass.
If you look on the grid docs page you can adjust the _setting.scss thus:
$row-width: rem-calc(1000);
$column-gutter: rem-calc(30);
$total-columns: 12 ;
Foundation Grid docs
When you say upgrade the CSS to future newer versions do you mean newer versions of Foundation? If you did a customised version download then you would probably need to do it again. If you are also do other styling changes on your site outside of the Foundation stuff and you are not going to use Sass, I think your best option would be to keep them on a separate stylesheet.
Without sounding like a Sass evangelist...it is really worth your while to use it. Makes life so much easier!
There is a CSS customizer that lets you choose up to 100 columns http://foundation.zurb.com/develop/download.html
Also you can change it in Sass to any number.
Related
Background
I'm trying to remove resize-observer-polyfill from an nx workspace that I'm working on because it's natively supported in the browsers that we are targeting. Once I removed the polyfill, I needed to add #types/resize-observer-browser because the workspace currently uses typescript#4.0.5 and my understanding is that TypeScript does not have a "native" type for ResizeObserver until v4.2 which I'd love to update to, but can't atm.
Problem
In order to make TypeScript happy, it seems like I have to go in and manually add "resize-observer-browser" to individual tsconfig compilerOptions.types entries. This didn't seem that bad to me at first. I just updated the tsconfig.lib.json file of the libraries that happened to utilize ResizeObserver. However, I soon realized I needed to also add it to the tsconfig.spec.json of the libraries so that the unit tests could run, and then I also needed to add it to the tsconfig.app.json of any applications that happened to import those libraries.
Question
Is there an easier way in an nx workspace to handle this sort of problem?
I think that I could remove the default types overrides in each of the tsconfig files, since that would let TypeScript just utilize everything that exists under node_modules/#types when compiling. I didn't want to take that path since I assume there is a good reason for the default nx library/app generators to add the types override (I assume it's to force you to be explicit and not accidentally get away with accidental imports of test code from business logic).
The docs seem to recommend against this for #types packages, but /// <reference types="..." /> (e.g. /// <reference types="resize-observer-browser" />) can be also be used to include types, and might be easier to manage if the type is only used in a few places.
Docs: https://www.typescriptlang.org/docs/handbook/triple-slash-directives.html#-reference-types-
In NatTable version 2 an autoscale was added while the tables are being created, supported by default DPI converters: DefaultHorizontalDpiConverter, DefaultVerticalDpiConverter. In version 1 everything under 96 DPI was not scaled down, however, now in version 2 for lower DPIs NatTables are scaled down hence images look ugly, fonts are ok:
72dpi - not ok:
96dpi - ok:
What would be the simplest way to prevent default scaling under 96 DPI?
The feature that was added with NatTable 2.0 is a complete dynamic scaling and the full support for all DPI. The following blog post should give some more details NatTable – dynamic scaling enhancements
Actually I wonder what is "ugly" with lower DPIs. At least on modern displays it should not be an issue. The only thing I could think of are the images. But typically downscaling doesn't make images ugly. So it would be really interesting to know what the issue is.
You have two options to handle that:
As you can scale NatTable dynamically at runtime, you can simply execute the ConfigureScalingCommand to force the scaling you want. Note that this needs to be done AFTER NatTable#configure().
if (Display.getDefault().getDPI().x < 96) {
natTable.doCommand(
new ConfigureScalingCommand(new FixedScalingDpiConverter(96)));
}
If you even want to block lower scalings on the dynamic scaling, you can implement a custom ConfigureScalingCommandHandler that checks for the dpiFactor in the IDpiConverter and if that is lower than 1 register a FixedScalingDpiConverter on the SizeConfigs. That custom ConfigureScalingCommandHandlerthen needs to be registered on the DataLayer to replace the default.
The second approach is probably a bit more complicated and needs a better understanding of NatTable internals. And it blocks the dynamic scaling feature to really zoom out on huge tables. So it depends on your use cases which approach to use. Typically the first option should be sufficient.
BTW, if the images are the issue, changing the scaling at runtime without re-registering the images could also cause a rendering issue. The reason for this is that images are stored in the ImageRegistry and they need to be updated there in case of scaling changes. For approach 1. that means to register all images in the ConfigRegistry again after the ConfigureScalingCommand. At least if you are not using themes or CSS styling.
I would like to paste the data-frame from the R environment to the latex part (question or solution part) when creating exercises in r-exams. Later the exercises will be imported into Moodle. Is that possible in r-exams? We saw it is possible when the object is matrix object via $\Sexpr{toLatex(matrix_obj)}$. But a similar way does not seem to work with the data-frames. Thank you!
A data.frame would usually be included as a {tabular} in LaTeX and there are various packages for automatic conversion like xtable or using the function kable() in knitr. For PDF output this also works nicely including all vertical and/or horizontal lines included in the table. However, for HTML-based output (as for Moodle) the table as such is converted correctly but without any lines.
An overview of a couple of solutions is available as:
Different copies of question with table for Moodle with R-Exams
Moreover, Kenji Sato has proposed to inject some dedicated CSS code to handle the table formatting in HTML. We are currently working on some automated way of including this in R/exams:
https://www.kenjisato.jp/en/post/2020/07/moodle-bordered-table/
I am using "pullerquest" in github to comment on examination after examination. It generates comments like this one:
Here, I can only see the top ten of issues.
How can I see all of the issues? Is there a link to the complete list of files?
As of the current version (1.4.1),
the maximum number of issues to display in that list is hardcoded at 10,
by the MAX_GLOBAL_ISSUES constant in the source code.
If you want to know more details, here's how the plugin operates:
The PullRequestIssuePostJob class creates an instance of GlobalReport here, calling this constructor, which uses the MAX_GLOBAL_ISSUES constant as the default maximum.
PullRequestIssuePostJob will process each issue, eventually ending up in GlobalReport.process method, where a conditional statement decides to register the issue if we are under the maximum, otherwise simply count it.
If you really want to see all issues, you could fork the code and change the constant to a higher number on this line.
As #JulienH pointed out in a comment, the size of GithHub comments is limited, so it is not possible to display an unlimited number of issues. This is why the cap on the number of issues displayed is necessary.
I am trying to generate a doxygen package with one enormous class hierarchy. (It's for QuickFIX, FWIW). No matter what I do, it seems to be capping the height of the image at 32766:
$ file html/inherit__graph__23.png
html/inherit__graph__23.png: PNG image data, 307 x 32766, 8-bit/color RGBA, non-interlaced
It's not clipping; it's scaling. The result is that at only 307px wide, the class boxes are scaled so small that the text inside them is not readable, and the HTML map doesn't work, either.
Neither the dot nor the doxygen documentation mention this limit, though it seems clear something is doing it, and I can't find any directives to override it. (And yes, I realize an image that big has its own problems in browsers, but I'll deal with that later.) That number seems suspicious due to its proximity to 2^15, and I believe PNG uses a 32-bit size field, so something bigger should be possible.
Anyone know where that limit is coming from and how to bypass it?
Edited to add: doxygen version = 1.6.1, graphviz = 2.26.0. Maybe too old?
Looks like I'm screwed. The 32K limit is imposed by cairo, which is what graphviz uses underneath the hood to render PNG.
Reference: http://comments.gmane.org/gmane.comp.lib.cairo/21068
Unfortunately, you're correct. It's too old; you're not going to be able to exceed that limit unless you manage to upgrade to a newer version.