What filetypes are supported by WebKit/chromium's renderer? I can't figure out what is in charge of the process of rendering non-HTML files from the chromium documentation.
Related
I am trying to add additional codec support to Chromium for HTML5 media play back. I've installed the package chromium-codecs-ffmpeg-extras to include a few more than what is included in original download.
I am curious if anyone knows the amount of work/ if its possible to fork the chromium code and add additional codec supports (.ts, .avi, etcc). Is it as simple as forcing chromium to use a different ffmpeg library or possibly use VLC to decode all of its videos?
I'm using gitlab to manage my repositories which has been quite pleasant so far. However the wiki could use a fair amount of improvement IMO.
It's really annoying when you already have documentation that you simply want to add to the wiki. Translating a table or pdf to gitlab flavored markdown can be time consuming and non-trivial.
My question is two-fold.
Has anyone had luck embedding files (specifically pdf's) into their github/gitlab wiki? This should definitely be possible on gitlab but is their an easy way to do it? I have a documentation repo set up, it would be awesome to embed files linked from the documentation repo.
If not embedding files into the pages. How do you efficiently translate a document to gitlab flavored markdown?
Had the same issue and landed here, maybe this helps somebody.
I didn't find a way to embed the .pdf into a page but what I did was to add the .pdf to the wiki folder (like a normal page). Initially this didn't show up in the sidebar nor was it searchable from Github.
It is possible however to link it directly from other pages or a custom sidebar (see for example osquery's wiki for a nice sidebar). Clicking on the link allows you to download the .pdf (didn't find a way to preview it in the browser)
It is possible that such action type is not allowed only in cloud gitlab version, cause gitlab-gollum lib documentation describes it so:
[[Gollum|gollum.pdf]]
I use Gitlab (self hosted) capabilities to render MarkDown pages regularly for documenting my projects.
The best way to copy paste html or pdf documentation and translate into perfectly formatted MarkDown is to use Typora. Typora has these very useful capabilities:
Support for Gitlab TOC rendering (i.e. [[_TOC_]])
copy and paste from HTML pages to MarkDown
upload of images
IMO is very easy to use for documentation with GitLab.
I wonder if is possible to package into an executable in VA Smalltalk. Posts on this subject seem to have contradictory or old information. The README from Instantiations comments about splash screen and other resource tweaks for client installs, but is not clear about making an executable application for distribution.
In that case:
Does generating an exe file implies stripping an image?
Is the image bootstrapped, i.e. built from scratch?
so here is my attempt to give a short answer.
You do ship several components when you deploy your application as a runtime:
Your stripped down image (VA ST has a very powerful tool called Packaged Image Browser for this task)
The Virtual Machine (a .exe on Windows). You can customize this exe to display your splash screen or your window icon.
A number of additional files that are needed by the VM and/or your image. These are pictures, message catalogs, additional DLLs etc. VAST has an exhaustive list of which files you have to ship if you use some feature of the product in the VAST documentation
So there is no mechanism to bundle VM and Image together and turn them into a single .exe file, like in Dolphin Smalltalk and maybe more. What you ship is usually a Directory with a few subfolders in it.
There's no way to embed the image (.icx file) into the executable (.exe file) with VA Smalltalk. The best you can do is have an exe file for the VM and your own custom icx file for the image plus a .ini file for configuration. The "Make Executable" option in the organizer creates these files for you but you still have several files.
Here is a good resource for starting out making runtimes.
Although, as mentioned, you can "Make Executable" from the option menu, my experience is based on the runtime packaging.
webkitters:
I'm brand new to node-webkit and am very excited by the Chrome-level compliance with HTML5 and CSS3,
as well as the benfits of node, itself. I am experimenting with font usage in an ePub3 reading application
and have been able to easily embed .ttf, .woff and (even) .svg fonts by using the #font-face CSS3 mechanism.
Not so with .otf (and IE's .eot) fonts. With the nw inspector, the elements show the proper font-family, the
font seems to load (no error messages in console) and the font resource shows up -- but the font does not appear.
The fallback system font shows, instead. This is a concern, because the ePub3 specification for reading systems
requires handling TTF and OTF embedded fonts. Chrome, itself, has supported OTF fonts for some time, I believe.
(I am working on a Windows system.) Does anyone have any information with respect to OTF fonts in Node-Webkit?
Is this an expected deficit, a known issue, a bug, or something unrelated? Any light shed on this issue would
be appreciated.
Thanks,
Jonathan (neologis)
Adobe Flash Player is a browser
plug-in that provides advantages for
users and content creators in the
browser, including the ability to
deliver RIAs in the browser. Adobe AIR
incorporates technologies originally
developed in Flash Player and enables
rich Internet applications on the
desktop. Adobe AIR and Flash Player
provide complementary deployment
methods for the RIAs.
as in here
Here are a couple of conceptual questions :
Since both runtimes consume .swf
files, what is the difference?
What is the end product of a compiled
AIR Application-a .swf/.air?
If AIR is just a deployment
mechanism, why is it called a
runtime?
Does Adobe AIR applications allow
states and transitions like a mxml
application ? -both can be authored
using Flash Builder
Adobe AIR runs on the same technology as Flash (i.e. your AIR apps will run in the Flash player.) The difference is the additional libraries available in AIR to allow you to more easily create Rich Internet Applications, as opposed to Flash itself which is targeted at animation and games creation.
The end product of a compiled AIR application is either a .air file or a natively packaged .exe/.dmg file (if targeted at the desktop in AIR 2+)
The .air file is just a zip file which contains a .swf file and relevant directories from your project (such as unembedded assets).
The .exe file is the same except for it also contains code to download and install the Adobe AIR Runtime if the user does not have it installed on their system. This can be very useful if you want your application to run only on the desktop as it means users won't get an 'open this file with..' message when they run the app without the runtime installed.
The Adobe AIR runtime is what allows your operating system to interpret .air files and install/run them on the system. It contains the relevant AIR libraries not included in Flash.
Adobe AIR when combined with Flex (mxml application) does allow states and transitions. States and transitions are a feature of Flex, so you would need to be using the Flex SDK in your project to use them.