The reality is that there's a lot more pragmatism applied in the real world than some of the posts here might suggest.
A great example: To the best of my knowledge, the in-app rendering of an E-Ticket that Trainline implement does not comply with or form the basis of any specific RDG specification. There simply
is no "in-app E-Ticket display" standard. There
is a spec for displaying an mTicket, but that has a different set of requirements. They've obviously made sure it's
close to the PDF display requirements and it follows the spirit of these guidelines fairly well, but to an extent they've just gone and done their own thing:
Has it been looked at by an accreditation analyst? Most likely. But the spec hasn't changed as a result of that.
If you're going to say that any ticket presented outwith the "official" display formats set out in the RSPS specifications is invalid, then you've suddenly criminalised every person using Trainline to purchase their tickets and you imply their tickets aren't valid unless they're open in Google/Apple Wallet. That would be nonsensical.
The reality for a passenger is that if it looks "good enough" with respect to the details shown, it's orange and it scans (i.e. you've not somehow failed to render the Aztec barcode properly), you're probably going to be fine. All the PDFs are going to be subtly different anyway by virtue of there being about a dozen different implementations using different technologies - some look very much like the engineer responsible has simply thrown the elements onto the page and taken very little care in lining up the different parts of the E-Ticket header, for example! Other TIS suppliers have decided they can't be bothered to render a visual itinerary diagram, and the spec does make some allowances for differences like this. If you print the E-Ticket, it's very possible that it'll be altered during this process as well as part of the process of optimising it for print.
If it doesn't scan or the member of staff has decided that scanning tickets is not a task they want to carry out, passengers should expect there to be more scrutiny of the human-readable parts of the ticket. I would hope that a passenger would be given the benefit of the doubt here - ideally if the unique ticket number is visible and there was some ambiguity over whether the ticket was legitimate or not because of how it looked, a revenue inspector would make a note of the details and arrange for the retailer to be contacted to double check if the ticket
was actually issued or not, and to discuss why the ticket didn't look legitimate.
Customers should be slightly careful with some of the alternative PKPass rendering apps available on Android, we've seen cases where one of the apps has managed to completely screw up rendering the Aztec barcode, which leaves it unscannable. If you're going to stray off the beaten path here you need to be completely sure of what you're doing and double check it is working as you'd expect, but ultimately one of the benefits of the E-Ticket system is
supposed to be that the security is provided by the barcode, its payload and the ticket validation systems that exist in the background. There are more important things the industry ought to be concerned about than how exactly Joe Bloggs presents that ticket, provided it was legitimately purchased from an accredited retailer.
The above only applies to E-Tickets. Digital Railcards, mTickets and a few other product fulfilment types have a significantly different security model.
