"When Unreal came out, it supported three renderer. Software, Glide, and PowerVR."
My MMX Pentium MMX 233MHz (512x384 with Creative Voodoo 2, patch patch 223 from https://oldunreal.com/downloads/unreal/oldunreal-patches/) benchmark, the intro goes from 60fps down to 10 fps when the whole castle is seen in the intro. When I start the game, in the cell, I can see 20fps.
I think the CPU is too light for this game. Definitely a title that requires a Pentium II.
I agree, if only because the UK seems to be the florida of goofball defamation cases. And while I do think the developer would win their case, having to field one at all really sucks.
In the UK, this is less of a problem, though it depends a lot on the contract between the company and the developer. Assuming nothing exotic, that the statement on the site is true (and not a malicious falsehood) and that if the hosting belongs to the end customer they did not revoke the developer's access (i.e. no unauthorised access occurred), then the developer is in a reasonable position legally. IANAL, of course.
No unauthorized access but they would argue unauthorized vandalism by the developer, which blocks the entire site.
Airing dirty laundry is in some jurisdictions a legal offence. Which is exactly why there needs to be agreement spelled out in contracts upfront, that this could happen, and the client would just sign it.
And I am a fan of smart contracts and cryptocurrencies, see my suggestion below:
Airing dirty laundry is in some jurisdictions a legal offence.
In the UK, the place where the site in the original link is, it's okay to state facts about a business transaction in public if it's not a malicious falsehood, a violation of contract, or a violation of privacy laws (e.g. sharing emails or recorded calls). But yes, I agree, the issues leading up to this should all be tackled by the contract up front.
You wouldn't own the land. It's quite common with small business web design for the developer to also control the hosting. The actual point in the web site case is that you are revoking the copyright license to the content until you receive payment, a well tested and accepted concept in UK law.
That said, there have certainly been situations where builders have gone back to properties and taken back their property (like tiles from walls, joinery, etc.) but I have no idea how that pans out legally as it's outside my wheelhouse.
When you don’t pay for your salesforce Licence it disables your integrations, and puts up a banner saying this has been done for non payment so you should contact an administrator.
Far be it from me to hold them up as a beacon of moral value, but in business it’s fair to say you have to pay for service.
Not the same thing. Salesforce is a service provider, they can stop the service they provide. This developer could too. Salesforce should not be allowed to cite payment reasons though.
You're opening yourself to claims of defamation, tortious interference, disparagement, even coercion, depending on where you are. Not saying the client will win, but they can make it so you'll need to pay lots of legal fees to defend yourself.
It's much smarter to just take the site down without any kind of message, or just something that says "temporarily unavailable". Play dumb with the client, say you don't know why it went down but to fix it but you need to be paid first. Or say it depended on cloud credits that were going to come out of payment, if you don't want it to look like the site went down due to your incompetence.
Making a big public stink might feel good, but it's not a smart business strategy.
Maybe. A lot of freelancers and agencies have amateur or no contracts.
A neutral service suspended message or no response from the server is more defendable if the client goes after you. If you actively communicate on their website, it could be argued you tried to cause reputational harm etc.
Even if you're right, provoking a legal response from a client is more than a lot of creatives and developers can handle, especially if the client is big enough to retain legal or staff a GC.
I suspect that things will turn out fine for this particular developer since the client seems small and the message is mostly innocuous.
But this is very obviously not "no stuff". This is "different stuff".
Taking the website down entirely or just blanking it out is a very, very different matter than replacing it with a different message; and doubly so when the different message is actively harmful to the customer. Unless the designer's contract with the customer explicitly allowed them to do this, this sort of thing is a slam dunk legal case of either vandalism (using a physical metaphor) or in the UK as in this example, a criminal violation of the Computer Misuse Act.
Not to mention that it's an enormous red flag that will scare away other potential customers for this designer; because it demonstrates that you're very willing to sabotage their operations.
You take a language designed around the limitations of 1970’s computers and the absence of limitations of Donald Knuth’s brain, and then you build a document system on top of that. What could possibly go wrong? =)
> I hate this language with the intensity of a thousand suns
Interesting. What's the main reason? Do you already have representative experience with Typst? Does it really solve the issues you perceived with Latex? Are you satisfied with the typographic quality of Typst? (why I'm interested: https://github.com/rochus-keller/typos/)
Thanks for the hints. The projects have different goals. My goal is to use a stand-alone luatex engine and integrate it with my new typesetting language, completely replacing TeX. MMTeX still uses TeX, but make an easier to install package using the OpTeX format; that's a very good approach for people who want to use OpTeX and don't care about the whole TexLive machinery. Speedata is closest to what I intend, but their language is XML based and optimized for catalogues, and they depend on a pre-existing luatex installation (so they could use mine instead). LuaMetaTeX is the successor of LuaTeX which essentially moves more implementation to Lua. To my surprise, I actually didn't find a pre-existing project so far which shares my goals.
Have you considered using ConTeXt's CLD [0]? It's still uses TeX underneath, but that's pretty well insulated from the end user. Here are some random examples that I've written [1] [2] [3].
I'm successfully using ConTeXt in a radar data evaluation and reporting project for more than ten years where a C++ based generator reads data from binary Matlab files and combines/formats them into perfectly layouted reports automatically. It's an impressive technology and if the users don't mind to have an extra ConTeXt installation on their system (which grows pretty large), the solution is perfect.
For my present project, I would like to start "from first principles" and not just add layers on top of things I don't fully understand. Thanks for the CLD document. I have read it when I started the mentioned project. I have no doubt from my own experience that the typesetting quality is excellent. But I consider using Lua for such large-scale achievements a mistake for architectural, maintainability und eventually performance reasons. The "flexibility" of this approach is payed with a high price.
Ah, nice! ConTeXt certainly isn't the solution to every problem, but it solves lots of the common complaints about LaTeX, and most people have never heard about it, so I always try and advertise it when I see a problem that seems like a good fit.
> if the users don't mind to have an extra ConTeXt installation on their system (which grows pretty large)
> For my present project, I would like to start "from first principles"
> But I consider using Lua for such large-scale achievements a mistake for architectural, maintainability und eventually performance reasons.
Well I personally disagree regarding Lua :), but all your points are very fair. Most people who say "I'm going to write my own typesetting system" severely underestimate the difficulty, but it sounds like you have a pretty good handle on the situation, so I'm rather hopeful that you'll accomplish your goal.
Once you're able to typeset something, we'd gladly accept a progress report at TUGboat [0], since this is a topic that lots of people are interested in but very few have accomplished.
Concerning Lua: there are approaches for years to add static typing to Lua, but from my point of view (as a language developer) none was really good when compatibility with Lua on language level (such as TypeScript vs. JavaScript) is a goal. With my own languages I only reused the engine without Lua compatibility, and the resulting language is much better suited for large-scale software engineering. But the approach based on LuaJIT turned out to be too brittle, so I switched to the CLI Mono engine, which is much faster (factor two) and much more stable.
> Once you're able to typeset something, we'd gladly accept a progress report at TUGboat
Currently I try to find out whether a Pascal based typesetting language with static typing would be worthwhile or not. Otherwise I will likely implement something like Typst (the latter is actually the reason I started this journey because it is for one part a much better language than TeX, but for the other part the typesetting quality is much worse, and this doesn't seem to change for years when looking at the roadmap).
Cool, good to know. But I assume you use a standard version, part of TexLive or a subset thereof? What libraries in addition to the luatex executable to you need? I'm currently integrating the fontloader into the executable binary so that I don't have to deploy a directory structure.
> so that I don't have to deploy a directory structure
LuaTeX itself doesn't depend on any particular directory structure. kpathsea does expect a certain directory structure, but you don't need to use kpathsea—LuaTeX was primarily developed for ConTeXt, which doesn't use kpathsea at all. Without kpathsea, you'll need to supply the appropriate callbacks in a Lua initialization script, but this is fairly simple.
Thanks, I've seen that. So far kpathsea didn't get into my way and caused less trouble than the Lua code I had to use to (hopefully) achieve optimal typsetting quality. But kpathsea is indeed on my list of disposable parts.
And for a system like speedata at least the Lua implemented luaotfload machinery had to be accessible somewhere in a known directory. When they now switched to LuaHBTex (as I likely will as well) this dependency can be avoided without losing typesetting quality (as far as I've understood so far).
I now have migrated LuaTex 1.10 and also 1.18 (with HarfBuzz) to my BUSY build system assuming that at least with the latter I could get rid of any TexLive dependency (especially the luaotfloader). I even implemented my own OTF loader in C (with Lua bindings for additional HarfBuzz functions) and added it to the LuaHBTex executable. The font loading works, and also the layout in principle, but the result is ugly. So I came to the conclusion that there is still a lot of Lua and TeX code required to get the famous LuaTeX typographic quality, and there is little chance to get it with only the LuaHBTeX engine itself.
What is your experience? Have you managed to use the LuaTeX engine stand-alone with decent results, or do you use additional TeX and Lua scripts?
Why such an old version? The latest version is 1.24.0, which should have lots of new features and fixes relative to v1.10. And if you're starting from scratch and not planning on using any of the TeX stuff, I'd really recommend using LuaMetaTeX since it cleans lots of stuff up, and doesn't use autotools at all.
The idea was to use the version which was officially declared as "complete" and also the last before the development of the HB integration started. My focus is on stability. The idea was to go with a minimal system and even integrate luatex-fonts-merged.lua as part of the binary, so there are no external dependencies.
The problem seems rather to be, that luatex-fonts-merged.lua is not really usable outside of the ConTeXt or TexLive tree, because it makes a lot of assumptions which are not met in my environment, and finding such dependencies in ~40kLOC of a dynamic language is nearly impossible. There was e.g. the assumption that the global utf variable pointed to unicode.utf8 (at least that's what I assume). So I had to set that before loading luatex-fonts-merged.lua. I assume there are many more such "tricks". After two days of experimenting, not even a "Hello World" is properly typeset. First the two words were apart half a page, and now they are set on two lines and I don't find out why.
These experiments brought me to the conclusion, that implementing so fundamental and complex logic in Lua is a very bad idea. So I'm currently evaluating LuaHBTex in the stable version 1.18.0. I like that it is still in C99 and C++ <= 11 (at least that's what I understood so far). I also had an intense look at LuaMetaTeX but don't like the architectural decision to do even more stuff in Lua. I'm using and integrating this language since 25 years and think it is good for a bit of glue code (max. 1-2 kLOC), but larger code bases pass the limit of practicability of a dynamic language. I even implemented a few statically typed languages which generate Lua source and bytecode to reuse the technology without this disadvantage.
> The idea was to use the version which was officially declared as "complete" and also the last before the development of the HB integration started.
HB is implemented as just another library, and it's pretty easy to exclude with the build script (ConTeXt does this).
> The problem seems rather to be, that luatex-fonts-merged.lua is not really usable outside of the ConTeXt or TexLive tree
So option 1 is to base things off of `luatex-plain` [0], which I believe is fully self-contained, but mostly undocumented. Option 2 is to base things off of luaotfload, which only depends on lualibs and luatexbase.
> There was e.g. the assumption that the global utf variable pointed to unicode.utf8 (at least that's what I assume).
It needs to be in the environment where you load the file, but that doesn't necessarily need to be the global environment. This is the fourth argument of the Lua "load" function.
> First the two words were apart half a page
I would randomly guess that your issue is that \parfillskip is initialized to 0pt from iniTeX, so the problem might go away if you typeset the text in an \hbox or node.hpack, or if you set \parfillskip/tex.parfillskip to "0pt plus 1fil".
> I like that it is still in C99 and C++ <= 11
I think that the latest versions of LuaTeX still only use C99 features, but they're also C23 compatible. The only thing that should use newer versions of C++ is HB I think.
> I also had an intense look at LuaMetaTeX but don't like the architectural decision to do even more stuff in Lua.
Fair enough :). The main thing that was moved from C to Lua was the PDF backend, because it's seriously unfun to write a PDF parser/writer in C.
Just wanted to say that I skipped LuaTex 1.10 because not even a bare Hello World worked. So I switched to LuaTex 1.18 including the HarfBuzz library. I even implemented my own OTF loader in C (with Lua bindings for additional required HarfBuzz functions) and added it to the LuaHBTex executable. The font loading works, and also the layout in principle, but the result is ugly. So I came to the conclusion that there is still a lot of Lua and TeX code required to get the famous LuaTeX typographic quality, and there is little chance to get it with only the LuaHBTeX engine itself.
For that reason I now left LuaTeX altogether and re-start with my own implementation of the Knuth algorithms based on HarfBuzz, FreeType, MicroTeX and Cairo. For the time being I limit the typesetting to western languages (LTR-only), which I hope allows me to get a working MVP version in a few months.
I have that on the radar indeed, but as far as I understand it still depends on plain.tex which again depends on tons of 1986 stuff (like old fonts) which I want to avoid. But due to my present experiments with the 40kLOC Lua machinery I'm scared of integrating this thing and would rather opt for avoiding it.
> that \parfillskip is initialized to 0pt from iniTeX
I did a lot of instrumented runs where values were printed and looked "unsuspicious". My best guess at the moment is that the Lua based machinery has an issue with the space in DejaVuSans.ttf, but that's just an assumption. I already stopped this path due to its apparent fragility and my reluctance of the architectural approach (I initially thought that everything required to do high-quality typesetting was already part of the luatex executable, but only realized this fragile dependency when doing larger test cases on my downsized engine version).
The dependencies might have a minimum C++ version, but I'd be pretty surprised if the core LuaTeX files couldn't be compiled with C99/C11. The recent C23 commits are just about adding support for compiling in C23 mode, so the main change is no longer using the implicit "everything is an int" function prototypes.
Thanks. The HB C++17 dependency is already a show-stopper for me. I want to be able to build everything on GCC 4.8, or even better 4.7. I also did some research what actually changed since 1.18.0 and didn't find features my project would depend on.
"When Unreal came out, it supported three renderer. Software, Glide, and PowerVR."
My MMX Pentium MMX 233MHz (512x384 with Creative Voodoo 2, patch patch 223 from https://oldunreal.com/downloads/unreal/oldunreal-patches/) benchmark, the intro goes from 60fps down to 10 fps when the whole castle is seen in the intro. When I start the game, in the cell, I can see 20fps.
I think the CPU is too light for this game. Definitely a title that requires a Pentium II.
Note that all fps gathered with "stat fps". There is a timedemo (https://www.gweb.me.uk/gweb/unrealsetup.htm) that I shall give a try someday.
reply