Enhance include ubuntu mono font#1446
Conversation
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
…ce display Adds the missing code to store the Ubuntu fonts into a resource file; but given that Linux distro package creators may already have the fonts in their native package range (or they do not accept the font as one they can distribute) steps have been taken to separate out the font resources into a separate resource file that can be omitted at build time with an environment variable "WITH_FONTS" set to have the value "NO". As it happens, at the time of writing the Ubuntu fonts had just been lined up to be placed into the "non-free" area of the Debian "unstable" version (it has been waiting around seven years because the Ubuntu Font Licence was just restrictive enough not to be acceptable to the DFSG - it required a certain form of naming of *modified* versions and that seemed to impinge on a freedom that Debian demands for "Free" software). Ideally I would have liked to not have the font files embedded directly into the source code and instead arranged for them to be obtained from upstream (currently: https://launchpad.net/ubuntu/+archive/primary/+files/ ubuntu-font-family-sources_X.YY.orig.tar.gz ) directly but only if they were wanted. This commit adds ALL the remaining (non-Monospaced) Ubuntu fonts from the original source to Mudlet. As there is a need to include the specific licence file for these fonts in our "About Dialog" but only if they were required - this justified my importing code similar to that which I will be using to provide translations of the GUI part of the application. Specifically it moves the HTML used for the textual content for the licence and about details from the UI form file to a C++ source file. This has to happen to allow for variations in the content to depend on build and/or run-time conditions and also makes it possible avoid the horrendous obfuscation that Qt Designer wreaks on any HTML it gets it's hand on. By using a modular coding style it was possible to boiler-plate multiple instances of various free but non-GPL licences that we must include - and to omit things that are not required for different build configurations, such as not including the licences for the recently added updater components on builds that do not include them. Note that the line: Q_INIT_RESOURCE(mudlet); should not be included in main.cpp as that macro is only needed for Qt library projects and not application ones - it has been removed. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
|
Um. a WIP as I forgot the CMake project file(s) stuff but |
src/mudlet.pro
Outdated
| isEmpty( FONTTEST ) | !equals($$upper(FONTTEST), "NO" ) { | ||
| # Include the font resources (by defining "INCLUDE_FONTS", like a | ||
| # "#define INCLUDE_FONTS" C preprocessor) if WITH_FONTS is NOT defined in the | ||
| # environment or is NOT set to a case insensitive "no" |
There was a problem hiding this comment.
This is confusing - a) are fonts included by default? (they should be) and b) how can one disable them easily?
There was a problem hiding this comment.
A). Yes
B). In a *nix shell set the environmental variable WITH_FONTS to (case insensitive) no; other OS have other comparable means. Typically this means doing something like
export WITH_FONTS="no"
before running qmake (or once I do the next commit cmake)...
Recent Qt Creator versions allow manipulation of variables like this for builds done within themselves:
Notice that there is a summary at the top of the selection which indicates what Qt is "doctoring" for the build environment (and you can see I am also tweaking a couple of my locale settings) - there is a similar section (in the Qt Kit "Run" part, the above screen is the "Build" one) for when running the application from within the IDE - that is very useful for testing the I18n GUI stuff for the "auto" locale choice as it means I do not have to reset my whole desktop to French/Russian/Chinese to check that that option will work... 🤓 😀
The reason I strongly urge us to support environmental variable controls for build options is that there is no need to modify the project files (and thus tickle git) to change the configuration of what gets built - which makes things nicer for the packagers such as @csmall .
Sadly I had to abandon some project file stuff to download the font files from the Ubuntu server only if needed because although I had something that would work for Linux (with wget + tar) I could not manufacture something we could rely on for macOs & 'Doze and I would need something to cover all of them before I cut the new Font files from being directly included in the source as they are with this (and @zzbazinga 's) original attempt.
Such environmental variables are also something that can be (possibly on a temporary basis) varied in the CI build matrix for testing - although to keep the standard test CI jobs per build count down, this would want to be reset before final commitment to the development branch.
There was a problem hiding this comment.
OK, how about this comment then, I think it will be clearer:
Do export WITH_FONTS="no" to disable...
Ehh wait, what are we disabling? Why not just load fonts if they are available and don't load them if they're not?
There was a problem hiding this comment.
Because they are currently included in the source (I would like them not to be but I cannot make that so at the moment) but packagers (or those who have the fonts already in their systems) will not want to bloat the executable with them or do not want them included in binaries that have licensing conditions that prevent the fonts from being included in their distributions.
There was a problem hiding this comment.
tl;dr; Mudlet is in the "main" section for Debian - including the Ubuntu fonts in the binary package means it becomes, I believe, "non-free" see https://www.debian.org/distrib/packages#note ...
Also tweak the commenting of the WITH_FONTS environmental variable used to control the feature in the qmake project file. Temporarily expands the CI build matrix to verify the option works on all 3 main platforms supported. Added .appveyor.yml to files tracked in Git repository and displayed in qmake-based Qt Creator environment. ## DO NOT MERGE THE PULL-REQUEST WITHOUT THE CI BUILD MATRIX BEING RESET ## Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
The Travis CI build was error-ing out in the CMake Qt 5.6 Linux build because that one did not have the WITH_FONTS value set. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
|
Can we keep things simple? Let's take a step back and this for what it is - we're just bundling two fonts with the application and that's it. It should be a trivial thing. Let's keep it simple as possible. |
.travis.yml
Outdated
| - Q_OR_C_MAKE=cmake | ||
| QT_VERSION=59 # actually 5.9 | ||
| QT_VERSION=59 | ||
| WITH_FONTS=NO # actually 5.9 |
There was a problem hiding this comment.
Is this just for the PR or intended to go into the repository?
There was a problem hiding this comment.
Just for testing - it expands the CI build matrix more than I would like (I spent several hours late last night/early this morning watching the Travis MacOS jobs backlog declining slightly - WTF happened at 04:00 UTC - and I do not want to load that more than I have to). Will revert now the code compiles on everything.
CMakeLists.txt
Outdated
| # INCLUDE_FONTS is a C preprocessor symbol (i.e. the same as | ||
| # "#define INCLUDE_FONTS" which, in the absence of an explicitly set | ||
| # value, takes the numeric value of (int)1 as far as the compiler is | ||
| # concerned!) |
There was a problem hiding this comment.
Could we condense this comment to just to disable font inclusion in the binary, set the environment variable INCLUDE_FONTS to "no"
There was a problem hiding this comment.
I wanted to explain the differences between the entities I was using - there are differences between how they behave (AFAICT) and if something doesn't work in the future (or if someone is porting to a different platform) it does not hurt to explain what is supposed to be going on; and, although the intention was to have the same action in both the cmake and the qmake cases there are slight differences - again AFAICT.
OTOH I suppose that, as the bottom line is that if the user does not do anything the default behaviour is as before, those who will want to tweak the settings are more likely to have a handle on the knobs to frob. 🤔
There was a problem hiding this comment.
I still want to keep it simple. Having lengthy explanations hurts because people read them even if they don't need to, get confused by them, become unsure if they were supposed to understand them, and then think the whole project is complicated.
There was a problem hiding this comment.
Conversely though, having undocumented options that are not explained is even worse in my book having properly commented stuff (and meaningful variable names) is always better than obscure settings whose effects can make things unworkable. It is a fine line though, and one that is subject to a certain amount of personal opinion.
There was a problem hiding this comment.
I did not propose to remove the text entirely - see my original comment:
Could we condense this comment to just
to disable font inclusion in the binary, set the environment variable INCLUDE_FONTS to "no"
Even simpler - and more correct, yes I also got confused by the explanation that was explaining far too much, just this would be super clear:
to disable font embedding in the binary, do: export WITH_FONTS="no"
Why not keep things super simple and crystal clear?
Think about your audience. Whom are you writing this for? The Linux packager, because that's the only person who has a practical use for this variable. When their goal is to disable the built-in fonts to comply with the licensing guidelines, do they need to know or worry about CMake variables or the C preprocessor variables? Not really. All they want to do is disable the fonts and they want to learn how to do that in the fastest way possible. Hence my suggestion that goes straight to the point!
Let me know what you think 😄
There was a problem hiding this comment.
OK, will rethink this...
There was a problem hiding this comment.
... have done something here!
CMakeLists.txt
Outdated
| # https://launchpad.net/ubuntu/+archive/primary/+files/ubuntu-font-family-sources_X.YY.orig.tar.gz | ||
| # TODO: automate the download and extraction of all the font and associate | ||
| # documentation but NOT the "sources" sub-directory contents into the | ||
| # ./src/fonts/ directory structure if this option is set to ON... |
There was a problem hiding this comment.
This is not something that should be done, I don't want to see increased complexity and machinery in the build process without a very good reason. We have git submodules for this and that's far enough.
There was a problem hiding this comment.
I do have a concern that some distros will be forced to drop Mudlet (or relegate it to a lesser availability) because we are include material which they do not want to include in their main area. The existing Deja Vu fonts are not a problem for Debian - who ARE a major Linux Distribution and the parent of many of the 500 or so active derivatives (consider https://en.wikipedia.org/wiki/Linux_distribution#Widely_used_distributions) but both they and Fedora have had issues with the Ubuntu fonts which have not yet been completely solved. By not including the font files in the source but only downloading them if they are wanted we could keep them happy. Remember that distribution of the Mudlet source code will include these fonts and even if we (or a packager) keeps them out of precompiled binary packages their presence may be problematic as in holding the source packages on their servers will probably count as "Propogation" as far as the Licence itself details:
To "Propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification and with or without charging a redistribution fee), making available to the public, and in some countries other activities as well.
If I could find a Git Repo of the Ubuntu fonts I am happy to copy-paste-revise the existing sub-module code to grab the most up to date release version - but Ubuntu uses bazaar on Launchpad and whilst the binary (without the source files which requires proprietary {non-free} tools to work on those source files) are available from https://assets.ubuntu.com/v1/fad7939b-ubuntu-font-family-0.83.zip - there is not a uniform tool to download and unzip that on all platforms as far as I can tell - (unlike git which does have the same commands on all of them)!
There was a problem hiding this comment.
OK, it's a theoretical concern, but theory differs from practice - until we have someone ask us to change, I don't want to default to a super complicated build setup. I'd like it to be simpler, not more complicated!
src/dlgAboutDialog.cpp
Outdated
|
|
||
| mudletTitleLabel->setPixmap(QPixmap::fromImage(splashImage)); | ||
| // clang-format off | ||
| // Do not let code reformatting tool mess this around! |
There was a problem hiding this comment.
We don't need a comment for a comment telling the formatter not to format! It only reads one.
There was a problem hiding this comment.
The second is my justification to (human) coders/hackers as to why the first is there (to the formatter) - I am trying to keep it as readable as possible and the layout is my best effort to do so - letting clang-format "clean" it up when it does not correspond to the general "style" is not going to leave me feeling warm and fluffy!
There was a problem hiding this comment.
We know what it means though, so it's unnecessary prose we have to read. We don't explain every single detail of the C++ standard either or how Qt works 😛
|
Technically, seems to work great! I'm just pushing back against the increased complexity of things... |
In my opinion the (optional) inclusion of the Ubuntu Fonts exposed an issue that would probably have had to be addressed anyhow - the 3rd party licence listing. All those non-GPL bits of code have to be reported in order to meet their Licence terms and with some bits only being needed in some circumstances a one-size include everything tab wasn't going to cut it¹. If we decide NOT to go ahead with them I think we still would have to go down this route (or else, I guess, we might get people on say, Windows asking what is all the "Sparkle" stuff for - where is it - or those using a Debian package wondering "where is the 'updater' - do I have to use that to keep Mudlet up to date"?) 1 - I guess I could clone this PR - cut out the font stuff and then put it forward as a "Licence clean-up" PR - leaving the Font as a separate issue... |
Conflicts resolved in: * .travis.yml * 3rdparty/lcf * CMakeLists.txt * src/CMakeLists.txt * src/mudlet.pro Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Messed up the merging of development and lost the change to a later commit in that git submodule - this restores it... Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Report two optional features at the same time and with the same messages on both CMake and QMake build systems. Also revise a comment about only downloading the "optional" fonts if needed to no longer be a "TODO:" but instead a "it is a nice idea but not needed right now and anyhow would add complexity"... Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
vadi2
left a comment
There was a problem hiding this comment.
Works great technically! 🎆 🎆
Only have some trivial comments
CMakeLists.txt
Outdated
| # INCLUDE_FONTS is a C preprocessor symbol (i.e. the same as | ||
| # "#define INCLUDE_FONTS" which, in the absence of an explicitly set | ||
| # value, takes the numeric value of (int)1 as far as the compiler is | ||
| # concerned!) |
There was a problem hiding this comment.
I did not propose to remove the text entirely - see my original comment:
Could we condense this comment to just
to disable font inclusion in the binary, set the environment variable INCLUDE_FONTS to "no"
Even simpler - and more correct, yes I also got confused by the explanation that was explaining far too much, just this would be super clear:
to disable font embedding in the binary, do: export WITH_FONTS="no"
Why not keep things super simple and crystal clear?
Think about your audience. Whom are you writing this for? The Linux packager, because that's the only person who has a practical use for this variable. When their goal is to disable the built-in fonts to comply with the licensing guidelines, do they need to know or worry about CMake variables or the C preprocessor variables? Not really. All they want to do is disable the fonts and they want to learn how to do that in the fastest way possible. Hence my suggestion that goes straight to the point!
Let me know what you think 😄
src/dlgAboutDialog.cpp
Outdated
| "<p><span style=\"color:#bc8942;\"><b>Blaine von Roeder</b></span> () joined in December 2009. He has contributed to the Lua API, submitted small bugfix patches and has helped with release management of 1.0.5.</p>\n" | ||
| "<p><span style=\"color:#bc8942;\"><b>Bruno Bigras</b></span> (<span style=\"color:#0000ff;\">bruno@burnbox.net</span>) developed the original cmake build script and he has committed a number of patches.</p>\n" | ||
| "<p><span style=\"color:#bc8942;\"><b>Carter Dewey</b></span> (<span style=\"color:#0000ff;\">eldarerathis@gmail.com</span>) contributions to the Lua API.</p>\n" | ||
| "<p><span style=\"color:#bc8942;\"><b>Erik Pettis</b></span> (<span style=\"color:#40b040;\">Oneymus</span>) developed the Vzyor GUI Manager for Mudlet.</p>\n" |
There was a problem hiding this comment.
That would be Vyzor. He also helps users in the Discord channel!
src/dlgAboutDialog.cpp
Outdated
| "<p><span style=\"color:#bc8942;\"><b>Carter Dewey</b></span> (<span style=\"color:#0000ff;\">eldarerathis@gmail.com</span>) contributions to the Lua API.</p>\n" | ||
| "<p><span style=\"color:#bc8942;\"><b>Erik Pettis</b></span> (<span style=\"color:#40b040;\">Oneymus</span>) developed the Vzyor GUI Manager for Mudlet.</p>\n" | ||
| "<p><span style=\"color:#bc8942;\"><b>\"ItsTheFae\"</b></span> (<span style=\"color:#40b040;\">Kae</span>) someone who has worked wonders in rejuventating our Website in 2017 but who prefers a little anonymity - if you are a <i>SpamBot</i> you will not get onto our Fora now. They have also made some useful C++ core code contributions and we look forward to future reviews on and work in that area.</p>\n" | ||
| "<p><span style=\"color:#bc8942;\"><b>\"dicene\"</b></span> (<span style=\"color:#40b040;\">Ian</span>) joining us 2017 they have given us some useful C++ and Lua contributions.</p>\n" |
There was a problem hiding this comment.
He's listed in copyright by name and email - could do the same here :)
There was a problem hiding this comment.
Okay - I'll recheck those details, note that I'm including Github Ids in the same colour as the Github links at the top of the page... 😁
src/dlgAboutDialog.cpp
Outdated
| // Only the introductory text at the top and interspersed between is to be | ||
| // translated - the Licences themselves MUST NOT be translated: | ||
| QString thirdPartiesHeader( | ||
| tr("<h3>Mudlet makes use of some third-party <i>non</i>-GPL software libraries which are listed here with their license information:</h3>")); |
There was a problem hiding this comment.
Would just going with third-party software libraries be an issue for you?
There was a problem hiding this comment.
Sorry, but yes it would, because the GPL ones specifically do NOT have to be listed as their licences do not require it and the only reason we are including these here is because we have to... (perhaps that sounds a bit harsh, but it took me a while to suss out the details, and these things being non-GPL makes it harder to use them and maintain a complete and full list of their terms of use) TBH I am not 100% certain I have nailed down all the licences but with the framework here it should be a little easier to insert further entries if needed.
There was a problem hiding this comment.
Yes, you've done a ton of work on this! Much appreciated :)
How about this positive-sounding stuff, because all of this is open-source at the end of the day and that is what really matters:
Mudlet is built on the shoulders of giants. Here are some of the third-party non-GPL libraries we make use of:
There was a problem hiding this comment.
I can use:
Mudlet is built on the shoulders of giants. Here are the third-party non-GPL libraries we make use of:
Mustn't admit that we are not listing something that we do have to - we have to be believe the list is complete... 😀
There was a problem hiding this comment.
Looks good, a bit lengthy, how about this:
Mudlet is built up the shoulders of others in the FOSS world; as well as making use of many GPL components we also make use of third-party non-GPL software:
I don't think it is interesting to know what needs to be mentioned and what doesn't need to be mentioned.
h3 is also supposed to be a header and this is too big to be a header, so how about just bolding it?
There was a problem hiding this comment.
Well "making use" is almost repeated with "make use" in the same sentence - so I'll use:
Mudlet is built upon the shoulders of other projects in the FOSS world; as well as using many GPL components we also make use of some third-party non-GPL software:
I'll check the formatting again, IIRC <h4> is the next one down and that is left aligned rather than centred so that is probably not an alternative - mayhaps the shorter bit will look okay but if not I see what else works...
.travis.yml
Outdated
| matrix: | ||
| - Q_OR_C_MAKE=cmake | ||
| QT_VERSION=59 | ||
| WITH_FONTS=NO # actually Qt 5.9, non-default without fonts |
There was a problem hiding this comment.
Temporary extension, right? I'd rather just test with font inclusion in for the sake of reasonable-ish build times.
There was a problem hiding this comment.
Yeah, just for testing - will take the CI build matrix back down before merge.
| // https://anonscm.debian.org/cgit/pkg-fonts/fonts-ubuntu.git/ | ||
| // but there is a term in the Ubuntu licence that makes them currently (and | ||
| // for the prior seven years) not quite the right side of the Debian Free | ||
| // Software Guidelines. |
There was a problem hiding this comment.
Why would we need to worry about the status of our dependencies in downstream projects? 🤔 We have a lot downstream projects...
There was a problem hiding this comment.
Well if we poison our code with stuff they do not want to swallow they either have to cut out the tainted parts or drop the product - by keeping it simple for them to avoid the bits they don't want, it makes it more likely they will continue to package Mudlet rather than taking the other more drastic solution.
There was a problem hiding this comment.
Just an FYI, Mudlet is not a Debian project...
There was a problem hiding this comment.
But, sure, this can stay. Until someone else comes along favouring some other distribution and will want to add their downstream stuff too 🤔
| # linux-g++-32, linux-g++-64 | ||
|
|
||
|
|
||
| TEMPLATE = app |
There was a problem hiding this comment.
app is default already - no need to list it.
There was a problem hiding this comment.
It was already in the file I just relocated it...
There was a problem hiding this comment.
...but if it is redundant then it can go.
Simplify some comments in the project files. Revise some details in the About Mudlet dialog. Prevent some messages being show thrice on platforms that parse the qmake project file three times. Corrected minimum Qt version for use of Qt5GamePad module from 5.8 to 5.7 . Corrected an error that failed to include font files as a resource file in CMake project file. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
|
@vadi2 right I've tried to come to a compromise over the contentions we have had above. There is one niggle that I'd like to resolve before we are done and that is the line: I am aware that the source code is under GPL 2 (or at the user's option) any later version. Given that we are not currently using any Qt component that requires GPL 3 (or later) it is okay to only use 2.0 for the binary but why do we not extend the same freedom to the binary as the source code and have that line read: instead? |
|
How about we do that in a follow-up PR? Changing the license in a PR focused at adding a new font seems way offtopic! |
|
😊 um, adding font -> adding it's non-GPL licence when needed -> review/rework/improve presentation of license information -> discrepancy in other licenses' details; it is a slippery slope! As I said, it is just a niggle (and contradicts
... but yeah, can defer it for now, just want to get this one in and off my task stack ... |
|
Okay, one last point left! |
Following more discussions with Vadim. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Removes testing for builds without the fonts in the binary. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
|
Following successful testing in da1e097 I've now returned the CI build matrix to normal (though there is commented out entries that can be uncommented again in the future if ever needed i.e. |
vadi2
left a comment
There was a problem hiding this comment.
@keneanung mind approving the infrastructure changes?
keneanung
left a comment
There was a problem hiding this comment.
A minor niggle about a comment, but otherwise this is ready to go.
CMakeLists.txt
Outdated
| endif() | ||
|
|
||
| # Enable the inclusion of fonts currently carried in the source code by default | ||
| # unless the environmental variable WITH_FONTS is defined and is not set to |
There was a problem hiding this comment.
Shouldn't this read [...]is defined and is set to[...]?
There was a problem hiding this comment.
Ah, yeah a double negative! Will touch that up... No that IS right - if WITH_FONTS is not defined the fonts ARE included; if it IS defined then ONLY if it is equal to the regexp equivalent to "[Nn][Oo]" are the fonts NOT included! Oh 'eck, it might not be not incorrectly put! 😖
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
|
Woohoo.. now a PR for that GPL thing? |
|
I'll need to know which way it should go: ❓ |
|
A sounds good.
…On Wed, 10 Jan 2018, 12:33 am Stephen Lyons, ***@***.***> wrote:
I'll need to know which way it should go:
A. Amend "About Dialog" to say "GPL 2, or later" {most likely, IMHO}
B. Amend everything to be "GPL3, or later" {unlikely}
C. Amend mudlet --version to output "GPL 2" only {would then match the
current "About Dialog" but not what I think should be done}
❓
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#1446 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAGxjI5UMT6ba22R4P4qkCPTAfna3pJLks5tI_dJgaJpZM4Q3lKe>
.
|
Brief overview of PR changes/additions
This is an improved (working) replacement for #1332.
Motivation for adding to Mudlet
The original had stalled as it did not load the fonts into the resource system for inclusion in the application - this one does.
Other info (issues closed, discussion etc)
There has been some licensing issues with this set of fonts in that they are not considered "free" enough to include in the "main" part of the Debian packaging system - the licence term has an unfortunate restriction on naming of modified versions - although eight days ago (after a seven year wait) the fonts have made it into Debian Unstable.
I have taken the liberty of adding the remaining non-Monospaced fonts as there are situations where those may also be wanted by users of Mudlet (composing documentation being the main one but also for use as a system font for the actual Mudlet application).
Importantly because I have made the include of all font resources a compile time option it was needed to allow conditional inclusion of the font licence in the application. As there are also other portions - particularly the Updater code - that had different OS Platform inclusion requirements for non-GPLed code I could see that it was necessary to bring the creation of the HTML content for the
dlgAboutDialogclass into the C++ from the Qt Design/QUiTools form/dialog - I had already gone that way for the current attempt to I18n the GUI so I ported across a sub-set of that code sufficient to create the HTML for that dialogue. Importantly it modularises the separate/repeated FOSS licences so it should be relatively painless (and trackable in Git) to add or remove future text content changes to the About dialog - which is almost impossible with the XML of the Qt Designer forms and which I know will be deeply unpleasant for translation in the XML form because Qt Designer has, since somewhere in the Qt 5.x series insisted on obfuscating even simple HTML into something that is unreadable in a raw form which is what translators would have to work with.