Sure, if you're doing a simple text transformation akin to the C preprocessor, then maybe that shouldn't be called a compiler. But we already have a word for that: "preprocessor". Which is probably why, as I mentioned in my other comment, Bjarne was miffed when I called Cfront a preprocessor - it was certainly nothing like the C preprocessor!
I guess in today's terminology I would have called it a "transpiler", because it simply transformed one source language to a fairly similar source language and didn't have to optimize the final machine code.
But there's a lot more to a compiler than optimization. Take TypeScript for example. Even though it generates JavaScript - and JavaScript that looks very much like the original TypeScript code if you're not having it translate newer syntax to older syntax - it does quite a bit of rather sophisticated work with all the type inference and type checking.
TypeScript doesn't need to worry too much about optimization, because it knows that the JavaScript engine that eventually runs the compiled code will do a bunch of JIT optimization.
Similarly, a compiler that targets LLVM or the JVM can rely on those engines to do much of the optimization. But the compiler is still a nontrivial piece of work.
Maybe I would suggest the term "preprocessor" for something that really is a just a simple text transformation, one that you might implement with regular expressions or hand off to a junior programmer.