Any submissions to MuPDF should try to match the existing coding style. While following the coding style does not guarantee inclusion, not following it will severely harm the chances of getting a patch accepted.
Details of the coding style can be found in docs/coding-style.html.
While it’s true that developers can always tweak a patch before they accept it (to make it follow whitespace, layout, naming, and other conventions), submitting a patch that requires such interventions is stacking the deck against it.
MuPDF is at pains to work everywhere. Submitting a patch that only works in specific circumstances (such as only working on Linux) is a sure-fire way to get rejected.
Similarly, pulling in new dependencies (be it new libraries or new functions that aren’t supported in all platforms) will make a patch unlikely to succeed.
MuPDF has a very consistent layout and whitespace style; patches that don’t follow the pattern will need to be refactored before they can be accepted.