BCD tables only load in the browser
text-rendering
The text-rendering CSS property provides information to the rendering engine about what to optimize for when rendering text.
The browser makes trade-offs among speed, legibility, and geometric precision.
Note: The text-rendering property is an SVG property that is not defined in any CSS standard. However, Gecko and WebKit browsers let you apply this property to HTML and XML content on Windows, macOS, and Linux.
One very visible effect is optimizeLegibility , which enables ligatures (ff, fi, fl, etc.) in text smaller than 20px for some fonts (for example, Microsoft’s Calibri, Candara, Constantia, and Corbel, or the DejaVu font family).
Syntax
/* Keyword values */ text-rendering: auto; text-rendering: optimizeSpeed; text-rendering: optimizeLegibility; text-rendering: geometricPrecision; /* Global values */ text-rendering: inherit; text-rendering: initial; text-rendering: revert; text-rendering: revert-layer; text-rendering: unset;
Values
auto Non-standard
The browser makes educated guesses about when to optimize for speed, legibility, and geometric precision while drawing text. For differences in how this value is interpreted by the browser, see the compatibility table.
The browser emphasizes rendering speed over legibility and geometric precision when drawing text. It disables kerning and ligatures.
The browser emphasizes legibility over rendering speed and geometric precision. This enables kerning and optional ligatures.
The browser emphasizes geometric precision over rendering speed and legibility. Certain aspects of fonts — such as kerning — don’t scale linearly. So this value can make text using those fonts look good.
In SVG, when text is scaled up or down, browsers calculate the final size of the text (which is determined by the specified font size and the applied scale) and request a font of that computed size from the platform’s font system. But if you request a font size of, say, 9 with a scale of 140%, the resulting font size of 12.6 doesn’t explicitly exist in the font system, so the browser rounds the font size to 12 instead. This results in stair-step scaling of text.
But the geometricPrecision property — when fully supported by the rendering engine — lets you scale your text fluidly. For large scale factors, you might see less-than-beautiful text rendering, but the size is what you would expect—neither rounded up nor down to the nearest font size supported by Windows or Linux.
Note: WebKit precisely applies the specified value, but Gecko treats the value the same as optimizeLegibility .
Formal definition
| Initial value | auto |
|---|---|
| Applies to | text elements |
| Inherited | yes |
| Computed value | as specified |
| Animation type | discrete |
text-rendering =
auto |
optimizeSpeed |
optimizeLegibility |
geometricPrecision
Attach an own mesher to OCC
is it possible to reprogramm the internal mesher or attach a completely new mesher to OCC?
I would like to generate meshes for each TopoDS_FAce with more control on edge size, aspect ratio and so on.
For OCC versions prior to 6.3 I just changed the internal call to triangle but since triangle was removed I am no longer sure how it is currently working.
Thank you in advance for any feedback,
- Log in to post comments
Roman Lygin
Wed, 08/05/2009 – 20:50
Yes, you can provide your own mesher to substitute BRepMesh_IncrementalMesh (which is default).
As of 6.3.0, Open CASCADE provides a plugin architecture for that. Release Notes do mention that but apparently User’s Guide does not uncover details.
Here is what you should do:
1. Subclass you meshing algorithm from BRepMesh_DiscretRoot and redefine its Perform() method using already saved shapes and parameters (deflection, angle, etc + optionally your own). This class must be located in a library (not executable)
1a. For convenience, it must also contain a static method
static Standard_Integer Discret (const TopoDS_Shape& theShape,
const Standard_Real theDeflection,
const Standard_Real theAngle,
BRepMesh_PDiscretRoot& theAlgo);
that will create an instance of your mesher using specified parameters. For instance:
Standard_Integer ExchangerLib_Mesher::Discret (const TopoDS_Shape& theShape,
const Standard_Real theDeflection,
const Standard_Real theAngle,
BRepMesh_PDiscretRoot& theAlgo)
theAlgo = new ExchangerLib_Mesher (theShape, theDeflection, theAngle);
return 0;
>
Alternatively, you must have another class with such static method.
2. Use DISCRETALGO macro defined in BRepMesh_PluginMacro.hxx to create a C function and export it. Its argument is a class that has above Discret() static method.
3. In your application, before it starts tessellating any shape specify your mesher as a new default using BRepMesh_DiscretFactory::SetDefaultName(). For example:
BRepMesh_DiscretFactory::Get().SetDefaultName (ExchangerLib_Mesher::LibName());
where argument is a name of the dynamic library that exports your function defined at step 2 above, without prefix and suffix (e.g. MyLib for libMyLib.so or MyLib.dll).
This will make it work.
However internal implementation is not optimal and has several issues (these are only those I noticed, in the order of decreasing severity):
a. It reveals big performance problems. If you have to visualize many individual shapes you will definitively notice that. The root-cause is that every time the framework employs OSD_SharedLibrary trying to load the library and resolve the symbol.
b. It does not provide a way to pass your own extra arguments to the mesher. The code assumes that only parameters available in Prs3d_Drawer will be used (deflection and angle) which is not a valid assumption.
c. Only one mesher at a time – you cannot tessellate shapes using different meshers in one AIS_InteractiveContext.
Alternative, more flexible solution would be to have Factory use some cache (as hash table or data map) that would store registered meshers and could dynamically select between them. The mesher would provide either a copy constructor or a Factory method (see Design Patterns) in order to fastly clone itself. But I have not really deeply thought of it (and I currently switched off a custom mesher).
Hope this helps.
Roman
—
opencascade.blogspot.com – the Open CASCADE blog
www.cadexchanger.com – CAD Exchanger, your 3D data translator
- Log in to post comments
dvdjimmy
Thu, 08/06/2009 – 09:56
Good morning Roman,
thank you for your detailed reply. Now its clear how to implement the mesher.
I think we will still do it a little bit different. Maybe you can tell me your opinion on it.
For the open source project FreeCAD we would like to implement a FE workbench. We use the CAD surfaces to allow the user to directly apply boundary conditions or forces on TopoDS_Faces or Topo_Edges. Afterwards we want to use netgen to generate a high quality mesh for us. This is something that should already work with nglib. Now comes the tricky part to map the generated mesh vertices and triangles to the corresponding TopoDS_FAces and Edges. The result of the mapping could be a struct where the ID of the TopoDS_Face and all the Nodes and triangles from the mesh which belong to it are referenced.
This way we wont have to dig into cascade too much and still can use a high quality mesh for our purposes.
Do you have a good idea how to do a fast and reliable mapping of the mesh nodes and triangles back to the TopoDS_Shape structure?
Best regards,
Joachim
- Log in to post comments
dvdjimmy
Tue, 08/11/2009 – 15:31
I am still stuck with my mesher problem. Roman, I have seen in your blog that your File Conversion utility also has an option to vary the visualisation mesh quality. Could you please share some information how you did it? Is everything done with OCC6.3 tools or did you develop own tools or algos for it? Of course, if anybody else can give some helpful feedback I would appreciate it a lot.
For the beginning this would at least help me to generate a high quality representation on screen. Of course the fine mesh is also much better suited to use it for FE calculation purposes.
Maybe I have to take special care of the deflection parameter which is required for the mesh as this seems to be the only input paramter available for the mesher.
thank you in advance for any kind of help.
With best regards,
- Log in to post comments
StefanKunze
Tue, 08/11/2009 – 16:10
Hi. I´m currently doing also research on the mesher. As far as I can say you can directly call
BRepMesh_FastDiscret like that f.e.
BRepMesh::Mesh(shape,deflection) does interally the same but with fast discret you have more options.
- Log in to post comments
Pierre Juillard
Tue, 08/11/2009 – 17:28
I don’t know if it can help, but maybe you should have a look at GMSH documentation or sources, or ask to its mailing list.
This open source mesher is based on the OCC library, and implements its own meshing algorithms, as well as netgen (would I know that it is feasible, I would recommend to integrate GMSH directly into FreeCAD as their data model are both based on OCC’s BREP to handle geometries).
Also, it can then output MED files to be used in Code_Aster.
- Log in to post comments
Pierre Juillard
Tue, 08/11/2009 – 17:36
. also it can read them back and offers thus a pre/post processing interface for Code_Aster without having all the dependcy troubles with Salome.
- Log in to post comments
dvdjimmy
Tue, 08/11/2009 – 18:06
@Stefan: Thank you for the suggestion within OCC. I think for the visualisation this might be a good way to control the quality a little bit better. Maybe Roman can also comment on this as he had to solve this problem as well 🙂
@yohplala: I already thought of GMSH and maybe this is really a good option for our FE integration. Especially the Code Aster integration and the netgen integration makes it very convenient. Are you already using GMSH?
Best regards,
Joachim
- Log in to post comments
Pierre Juillard
Tue, 08/11/2009 – 19:02
I tried GMSH just a bit, but in the end, as it is to carry out computations within Code_Aster, I jumped directly to “SALOME-MECA-2009.1.GPL” (release available on CAELinux: http://caelinux.com/CMS/index.php?option=com_content&task=category§i. ).
The integration with Code_Aster goes a step further.
Once you have a MED file (containing a mesh), before starting a Code_Aster computation, you still need a .comm file which is an ASCII file and which describes your material data, boundary conditions, loadings and basically what you want to do (implicit or explicit integration scheme, modal analysis, thermal anlysis, mechanical analysis. )
In GMSH, you can draw simple CAD and mesh them and finally have a MED file.
In SALOME_MECA, in addition to the GEOM module to draw CAD, the SMESH module to mesh (also including netgen, as well as other modules and GMSH algorithms are also foreseen there), there directly is the Code_Aster module in which you setup:
– the .comm file through the EFICAS utility: it basically has a dictionary of all the keywords a .comm file may contain, but also the description of the arguments these keywords may wait for, and so on.. It checks the validty of the .comm file you write. Writing a .comm with EFICAS is thus much easier than writing it in a text editor.
– the arguments to start the computation (memory, number of CPUs) and you can finally click on “Solve the Code_Aster case”.
As everything is packed in SALOME_MECA, I thus jumped to SALOME_MECA.
I already asked this in the FreeCAD forum and had negative answers from the FreeCAD team, but it really seems to me that it is much more interesting to integrate FreeCAD in SALOME_MECA (and benefiting from the exiting meshing algorithms, and Code_Aster, and YACS (to oneday achieve parameteric CAD optimization!) and Code_Saturne, and so on. than the other way integrating everything in FreeCAD.
Jürgen answered me that everything was in french and non-understandable with which I don’t completely agree.
In this power point focusing on the component model for computation (integration of Code_Aster, Code_Saturne and so on. ), you can have a sketch of the Salome organization p.12 (http://www.compframe.org/cbhpc2008/CBHPC08_Presentation/content/slides/0. )
One notices that one should focus on the Salome GUI and Salome Kernel to integrate a new CAD module.
The interesting points are that Salome makes use of OCC, Qt and python, just like FreeCAD, so it is all the more encouraging.
- Log in to post comments
Pierre Juillard
Tue, 08/11/2009 – 19:25
Thinking of it, I don’t criticize the FreeCAD Workbench facility.
It is for sure a very convenient tool to create additional modules such as:
– a module to fold a geometry
– a module easing the task of drawing stamping tools for press
– a module easing the taske of drawing a auto skins
. modules that are related to CAD and are based on a CAD model data.
But once getting interested in FE computation, the needed model data gets far more complcated and finally it takes years of engineers to build an integration platform such as Salome.
- Log in to post comments
Pierre Juillard
Tue, 08/11/2009 – 19:54
And also one of Jürgen’s argument was that in FreeCAD, the FE Workbench would only target basic FE applications.
However, I see a contradiction.
FreeCAD will as I understand it, be a key open source CAD application to handle assemblies (building of assemblies through a tree, use of a constraint solver, use of python to manage parametric CAD properties, and so on. ), which is not the GEOM module.
However, you simply can’t have “basic” FE applications with assemblies.
I work mainly in this field (evaluation of automotive assembly behaviours (manufacturing and evaluation of in-use properties)) and I can tell you that setting up an FE model for an assembly needs some specific tunings that I don’t see achievable in a CAD interface:
– tuning of the contacts between the parts (you can easily spend 80% of the time of building a FE model on this step, and it will be in 99% percent of the cases why your model doesn’t converge, more particularly in implicit simulations)
– building of the “assembly elements”: spotwelds, linewelds, rivets, bolt. the kind of things you don’t re-use from the CAD model because it has to be simplified by for instance beams linking nodes in the mesh. This you really need a specific interface to manage these entities.
This is why the integration of a FE Workbench in a CAD software seems very complex to me.
Dassault never succeeded correctly in Catia V5.
- Log in to post comments
dvdjimmy
Tue, 08/11/2009 – 22:09
Good evening yohplala,
thank you for your comprehensive comments about GMSH, SALOME and your experiences with FE.
I will try to explain in detail the main idea behind the FreeCAD FE workbench and also a little bit my background.
FreeCAD is in fact planned to be an open source alternative to CATIA V5 sometime in the future. This includes mainly workbenches for Part Design, Assembly, Meshing Tools, FE, Drawing and CAM functionality.
Until today we are proceeding quite well for the Part, Meshing Tools, Drawing and CAM modul. A lot of the already implemented functions like surface reconstruction, tool path generation for milling in different variations are yet not covered by the GUI but are already used in production from myself. Also springback compensation algorithms can be found in the code but have to be made visible to the users. In FreeCAD we implemented an own Mesh-Kernel which is very fast and provides a bunch of useful functions like OpenMesh is also offering.
Up to now we use the internal OCC meshing capabilities to generate a visualisation in conjunction with COIN3D. This visualisation does sometimes not look very good and therefore we wanted to tweak our code a little bit to get better visualisation results. So, for this case, its just a matter of viewing quality and performance.
For our algorithms like springback compensation, surface reconstruction its completely different. For these algorithms we need a high quality, homogeneous mesh to let our algorithms do a good job. This is currently not possible with the internal mesher, even if we generate more elements. Therefore a meshing alternative is heavily needed!!
As we reached this point we also spoke about implementing an FE Workbench which offers nearly the same convenience like CATIA V5 but up to now just for simple Part geometrys. NO ASSEMBLYS will be covered in the early steps. As I work with FE tools like Hypermesh, Medina, ABAQUS, LSDYNA everyday I know how much time it costs to really build up a high quality input deck. This of course is not the focus of FreeCAD. FreeCAD is more like ABAQUS CAE: Provide the user a convenient way to mesh its geometry, apply boundary conditions, define loads and generate an input deck which can be detailed further within Hypermesh or any other Pre-Processing tool. Also the solver integration will be limited to CAlculix at the beginning as I use it quite often. Code_Aster should just be an option and as I already used the CAELINUX stuff with Salome I know that FreeCAD should not attempt to rebuild Salome as this is not in the scope of the project.
To really implement a good way to mesh our geometries we also should be able to provide a quad mesher. Does anybody know if GMSH offers something like that. Triangles are good, of course but for FE Quad-Meshers are the tools of choice, even if its still hard for the professional programs to generate Quad-Meshes correctly.
I hope I was able to show you a litte bit the focus of the FreeCAD Team and that some of you are encouraged now to support us and also take part in the project 🙂
With best regards,
Joachim
- Log in to post comments
