Roland Perry <roland@perry.co.uk> wrote:
> In message <spc8ut$d2h$1@dont-email.me>, at 08:28:13 on Wed, 15 Dec
> 2021, Recliner <recliner.usenet@gmail.com> remarked:
>> Roland Perry <roland@perry.co.uk> wrote:
>>> In message <c63irgdtobo6i0690q7rs3h8mjrog2arbf@4ax.com>, at 21:35:13 on
>>> Tue, 14 Dec 2021, Mark Goodge <usenet@listmail.good-stuff.co.uk>
>>> remarked:
>>>> On Tue, 14 Dec 2021 21:15:49 +0000, Recliner <recliner.usenet@gmail.com>
>>>> wrote:
>>>>
>>>>> On Tue, 14 Dec 2021 19:24:03 +0000, Mark Goodge
>>>>> <usenet@listmail.good-stuff.co.uk> wrote:
>>>>>
>>>>>> On Tue, 14 Dec 2021 17:40:47 +0000, Roland Perry <roland@perry.co.uk>
>>>>>> wrote:
>>>>>>
>>>>>>> In message <spaivj$1j6$3@dont-email.me>, at 17:07:00 on Tue, 14 Dec
>>>>>>> 2021, Recliner <recliner.usenet@gmail.com> remarked:
>>>>>>
>>>>>>>> You can perfectly well view PDFs with no Adobe software installed.
>>>>>>>
>>>>>>> That's true, although the rail ticketing sites direct you very strongly
>>>>>>> towards using Adobe. Maybe that's something else they ought to review?
>>>>>>
>>>>>> I think the point is that Acrobat is both cross-platform and a dedicated
>>>>>> PDF viewer, whereas other apps may only work for one or the other
>>>>>> platform and other cross-platform apps, while they may do PDF as a
>>>>>> secondary function, are not aimed specifically at that use case. So
>>>>>> suggesting that customers install Acrobat is probably the simplest way
>>>>>> of helping those who do not already have a PDF viewer installed, because
>>>>>> the TOCs know it will work for everybody.
>>>>>>
>>>>>
>>>>> Adobe owns the PDF format, so there may be some requirement to mention it
>>>>> when recommending PDF viewers.
>>>>
>>>> Not any more, they don't. They did develop it, but it's been an Open ISO
>>>> Standard since 2008.
>>>>
>>>>> In any case, with large, complex PDFs (not rail tickets), not all
>>>>> viewers produce the same rendering, and it would normally be the case
>>>>> that the Adobe rendering is most likely to be correct (if only because
>>>>> it's the one rendering that's very likely to have been tested by the
>>>>> author of the PDF).
>>>>
>>>> The whole point of PDF is that it will look identical on any device when
>>>> rendered by any software. There are some advanced features, such as
>>>> editable forms and a document tree, which not all read-only viewers
>>>> support. But any given page of a PDF document will render identically in
>>>> any standards-compliant software.
>>>>
>>>> In any case, the key part of an e-ticket is the QR code, which is simply
>>>> an embedded image.
>>>
>>> That's interesting. Are you saying that the QR code is a jpeg embedded
>>> in the PDF?
>>
>> Obviously it's an image embedded in the PDF, but it's much more likely to
>> be a PNG or GIF than a lossy JPEG. What else did you think it might be but
>> an embedded image?
>
> A PDF vector map, like the rest of the document might be.
>

Yes, PDFs can contain vector diagrams, but I doubt that QR codes are. I
might try extracting one to see, but of course individual files could use
different image formats for them.

<martin.coffee@round-midnight.org.uk> wrote:
> On 15/12/2021 07:17, Tweed wrote:
>> Roland Perry <roland@perry.co.uk> wrote:
>>> In message <t02irgtihactd9p5p7bktssvd1cqbf203u@4ax.com>, at 21:15:49 on
>>> Tue, 14 Dec 2021, Recliner <recliner.usenet@gmail.com> remarked:
>>>> On Tue, 14 Dec 2021 19:24:03 +0000, Mark Goodge
>>>> <usenet@listmail.good-stuff.co.uk> wrote:
>>>>
>>>>> On Tue, 14 Dec 2021 17:40:47 +0000, Roland Perry <roland@perry.co.uk>
>>>>> wrote:
>>>>>
>>>>>> In message <spaivj$1j6$3@dont-email.me>, at 17:07:00 on Tue, 14 Dec
>>>>>> 2021, Recliner <recliner.usenet@gmail.com> remarked:
>>>>>
>>>>>>> You can perfectly well view PDFs with no Adobe software installed.
>>>>>>
>>>>>> That's true, although the rail ticketing sites direct you very strongly
>>>>>> towards using Adobe. Maybe that's something else they ought to review?
>>>>>
>>>>> I think the point is that Acrobat is both cross-platform and a dedicated
>>>>> PDF viewer, whereas other apps may only work for one or the other
>>>>> platform and other cross-platform apps, while they may do PDF as a
>>>>> secondary function, are not aimed specifically at that use case. So
>>>>> suggesting that customers install Acrobat is probably the simplest way
>>>>> of helping those who do not already have a PDF viewer installed, because
>>>>> the TOCs know it will work for everybody.
>>>>>
>>>>
>>>> Adobe owns the PDF format, so there may be some requirement to mention
>>>> it when recommending PDF viewers.
>>>>
>>>> In any case, with large, complex PDFs (not rail tickets), not all
>>>> viewers produce the same rendering, and it would normally be the case
>>>> that the Adobe rendering is most likely to be correct (if only because
>>>> it's the one rendering that's very likely to have been tested by the
>>>> author of the PDF).
>>>>
>>>> But I wouldn't have expected an experienced PC user (where the same
>>>> considerations apply) like Roland to have been tripped up so badly on
>>>> this trivial issue that doesn't seem to phase even novice mobile phone
>>>> users. It's as if Roland has only just acquired his very first Android
>>>> phone and is baffled by all the standard stuff that others take for
>>>> granted.
>>>
>>> An almost Norman-esque false premise there. My objection to PDFs is the
>>> way that it turns the delivery of tickets into a multi-phase process
>>> (which have several stages where extra glitches might, and indeed do,
>>> occur). Rather than simply using the 21st Century technology available
>>> within the mobile phone platform, to push them into the app's wallet.
>>>
>>> The secondary issue (which we should try to avoid hi-jacking the more
>>> fundamental proposition) is that the user might have to specially
>>> download and install (and possibly sign into) a PDF viewer.
>>
>> It’s already been pointed out to you that the apps accept tickets to their
>> in built wallet. PDF is an alternate means of delivery. Choice is a good
>> thing. If I were going on a long or expensive journey I’d print off the pdf
>> at home as a backup. My one real objection to phone based ticketing is that
>> they consider you to have no ticket if your phone fails. They make no
>> effort or provision to look things up on the back end, unlike an airline
>> (probably excepting Ryanair) who will find your booking if you wave your
>> passport at the desk. Even something like a nominal £1 fee to stop everyone
>> winding up the ticket inspector with spurious claims of phone non
>> functionality would be a step forwards.
>>
> Now that most (but not quite all) trains have USB charge points I
> suggest the time has come to make the flat battery rule only apply when
> there are operative charge points.
>
> XC Class 170s and the GWR HSTs are the only consists I know of without
> USB charge points.
>

I suspect that there are plenty of others. For example, the large fleet of
GTR 377s is only just beginning to have them fitted.

<martin.coffee@round-midnight.org.uk> wrote:
> On 15/12/2021 08:28, Recliner wrote:
>> Roland Perry <roland@perry.co.uk> wrote:
>>> In message <c63irgdtobo6i0690q7rs3h8mjrog2arbf@4ax.com>, at 21:35:13 on
>>> Tue, 14 Dec 2021, Mark Goodge <usenet@listmail.good-stuff.co.uk>
>>> remarked:
>>>> On Tue, 14 Dec 2021 21:15:49 +0000, Recliner <recliner.usenet@gmail.com>
>>>> wrote:
>>>>
>>>>> On Tue, 14 Dec 2021 19:24:03 +0000, Mark Goodge
>>>>> <usenet@listmail.good-stuff.co.uk> wrote:
>>>>>
>>>>>> On Tue, 14 Dec 2021 17:40:47 +0000, Roland Perry <roland@perry.co.uk>
>>>>>> wrote:
>>>>>>
>>>>>>> In message <spaivj$1j6$3@dont-email.me>, at 17:07:00 on Tue, 14 Dec
>>>>>>> 2021, Recliner <recliner.usenet@gmail.com> remarked:
>>>>>>
>>>>>>>> You can perfectly well view PDFs with no Adobe software installed.
>>>>>>>
>>>>>>> That's true, although the rail ticketing sites direct you very strongly
>>>>>>> towards using Adobe. Maybe that's something else they ought to review?
>>>>>>
>>>>>> I think the point is that Acrobat is both cross-platform and a dedicated
>>>>>> PDF viewer, whereas other apps may only work for one or the other
>>>>>> platform and other cross-platform apps, while they may do PDF as a
>>>>>> secondary function, are not aimed specifically at that use case. So
>>>>>> suggesting that customers install Acrobat is probably the simplest way
>>>>>> of helping those who do not already have a PDF viewer installed, because
>>>>>> the TOCs know it will work for everybody.
>>>>>>
>>>>>
>>>>> Adobe owns the PDF format, so there may be some requirement to mention it
>>>>> when recommending PDF viewers.
>>>>
>>>> Not any more, they don't. They did develop it, but it's been an Open ISO
>>>> Standard since 2008.
>>>>
>>>>> In any case, with large, complex PDFs (not rail tickets), not all
>>>>> viewers produce the same rendering, and it would normally be the case
>>>>> that the Adobe rendering is most likely to be correct (if only because
>>>>> it's the one rendering that's very likely to have been tested by the
>>>>> author of the PDF).
>>>>
>>>> The whole point of PDF is that it will look identical on any device when
>>>> rendered by any software. There are some advanced features, such as
>>>> editable forms and a document tree, which not all read-only viewers
>>>> support. But any given page of a PDF document will render identically in
>>>> any standards-compliant software.
>>>>
>>>> In any case, the key part of an e-ticket is the QR code, which is simply
>>>> an embedded image.
>>>
>>> That's interesting. Are you saying that the QR code is a jpeg embedded
>>> in the PDF?
>>
>> Obviously it's an image embedded in the PDF, but it's much more likely to
>> be a PNG or GIF than a lossy JPEG. What else did you think it might be but
>> an embedded image?
>>
>>> (There's still the open question why an e-ticket needs so
>>> much information, when an 8-digit code should be sufficient to index the
>>> database).
>>>
>>> (On a related note, I've always wondered why my scanner has options to
>>> produce jpeg or pdf files, when the latter appear to be simply a pdf
>>> wrapper around an otherwise identical jpeg. Not sure what extra it
>>> brings to the party, other than to satisfy organisations who might
>>> demand a pdf format for some internal reason of their own).
>>
>> Depending on how you intend to use the file, one format may be more
>> convenient than the other. PDFs can also be locked, unlike JPEGs.
>>
> PDF's can be unlocked easily enough. There's plenty of software around
> including password crackers.
>

PDF security may be breakabe by experts, but JPEGs have no security at all.

In message <spc9ts$imk$1@dont-email.me>, at 08:44:44 on Wed, 15 Dec
2021, Tweed <usenet.tweed@gmail.com> remarked:
>Roland Perry <roland@perry.co.uk> wrote:
>> In message <spc5sf$sbe$1@dont-email.me>, at 07:35:43 on Wed, 15 Dec
>> 2021, Tweed <usenet.tweed@gmail.com> remarked:
>>> Roland Perry <roland@perry.co.uk> wrote:
>>>> In message <c63irgdtobo6i0690q7rs3h8mjrog2arbf@4ax.com>, at 21:35:13 on
>>>> Tue, 14 Dec 2021, Mark Goodge <usenet@listmail.good-stuff.co.uk>
>>>> remarked:
>>>>> On Tue, 14 Dec 2021 21:15:49 +0000, Recliner <recliner.usenet@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Tue, 14 Dec 2021 19:24:03 +0000, Mark Goodge
>>>>>> <usenet@listmail.good-stuff.co.uk> wrote:
>>>>>>
>>>>>>> On Tue, 14 Dec 2021 17:40:47 +0000, Roland Perry <roland@perry.co.uk>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> In message <spaivj$1j6$3@dont-email.me>, at 17:07:00 on Tue, 14 Dec
>>>>>>>> 2021, Recliner <recliner.usenet@gmail.com> remarked:
>>>>>>>
>>>>>>>>> You can perfectly well view PDFs with no Adobe software installed.
>>>>>>>>
>>>>>>>> That's true, although the rail ticketing sites direct you very strongly
>>>>>>>> towards using Adobe. Maybe that's something else they ought to review?
>>>>>>>
>>>>>>> I think the point is that Acrobat is both cross-platform and a dedicated
>>>>>>> PDF viewer, whereas other apps may only work for one or the other
>>>>>>> platform and other cross-platform apps, while they may do PDF as a
>>>>>>> secondary function, are not aimed specifically at that use case. So
>>>>>>> suggesting that customers install Acrobat is probably the simplest way
>>>>>>> of helping those who do not already have a PDF viewer installed, because
>>>>>>> the TOCs know it will work for everybody.
>>>>>>>
>>>>>>
>>>>>> Adobe owns the PDF format, so there may be some requirement to mention it
>>>>>> when recommending PDF viewers.
>>>>>
>>>>> Not any more, they don't. They did develop it, but it's been an Open ISO
>>>>> Standard since 2008.
>>>>>
>>>>>> In any case, with large, complex PDFs (not rail tickets), not all
>>>>>> viewers produce the same rendering, and it would normally be the case
>>>>>> that the Adobe rendering is most likely to be correct (if only because
>>>>>> it's the one rendering that's very likely to have been tested by the
>>>>>> author of the PDF).
>>>>>
>>>>> The whole point of PDF is that it will look identical on any device when
>>>>> rendered by any software. There are some advanced features, such as
>>>>> editable forms and a document tree, which not all read-only viewers
>>>>> support. But any given page of a PDF document will render identically in
>>>>> any standards-compliant software.
>>>>>
>>>>> In any case, the key part of an e-ticket is the QR code, which is simply
>>>>> an embedded image.
>>>>
>>>> That's interesting. Are you saying that the QR code is a jpeg embedded
>>>> in the PDF? (There's still the open question why an e-ticket needs so
>>>> much information, when an 8-digit code should be sufficient to index the
>>>> database).
>>>>
>>> Because you might want to encode information for offline use. Consider an
>>> on train ticket inspector.
>>
>>> Their machine is never going to be 100% online due to the nature of land to
>>> train communications.
>>
>> Fair enough, so an e-ticket by design, but a bearer bond in practice
>> when the comms are flaky.
>
>There’s no shades of grey in your world are there? That’s at the root of a
>lot of the issues on here.

I'm not sure there *are* any shades of grey when it comes to definitions
like e-tickets and m-tickets. They are quite separate concepts.

Isn't that what you were getting at when you earlier said:

>the fact remains that an e-ticket is a pointer and an m-ticket is the
>actual ticket.
--
Roland Perry

In message <spcbav$r6c$1@dont-email.me>, at 09:08:47 on Wed, 15 Dec
2021, Recliner <recliner.usenet@gmail.com> remarked:
>Rolf Mantel <news@hartig-mantel.de> wrote:
>> Am 15.12.2021 um 07:45 schrieb Roland Perry:
>>
>>> (On a related note, I've always wondered why my scanner has options to
>>>  produce jpeg or pdf files, when the latter appear to be simply a pdf
>>>  wrapper around an otherwise identical jpeg. Not sure what extra it
>>>  brings to the party, other than to satisfy organisations who might
>>>  demand a pdf format for some internal reason of their own).
>>
>> I would doubt that the PDF on a scanner is a wrapper around the JPEG
>> format; mostly PDF (and TIFF) formats use a compression optimized for
>> documents while JPEG is a compression optimized for pictures.
>
>PDFs and TIFFs are lossless formats (TIFFs are usually uncompressed), while
>JPEGs always have lossy compression. I would think Roland is right here,
>and his scanner probably does capture a lossy JPEG, with an optional PDF
>wrapper.

The main cause of "loss", whichever format is output, is the setting on
the scanner for 100-600dpi, which it asks for every time.

In any event, selecting the PDF option appears to add about 20kB to the
output file, which sounds about right for a wrapper (rather than a
fundamentally different resolution).
--
Roland Perry

In message <spcbvm$v0u$1@dont-email.me>, at 09:19:49 on Wed, 15 Dec
2021, martin.coffee@round-midnight.org.uk remarked:
>On 15/12/2021 07:17, Tweed wrote:
>> Roland Perry <roland@perry.co.uk> wrote:
>>> In message <t02irgtihactd9p5p7bktssvd1cqbf203u@4ax.com>, at 21:15:49 on
>>> Tue, 14 Dec 2021, Recliner <recliner.usenet@gmail.com> remarked:
>>>> On Tue, 14 Dec 2021 19:24:03 +0000, Mark Goodge
>>>> <usenet@listmail.good-stuff.co.uk> wrote:
>>>>
>>>>> On Tue, 14 Dec 2021 17:40:47 +0000, Roland Perry <roland@perry.co.uk>
>>>>> wrote:
>>>>>
>>>>>> In message <spaivj$1j6$3@dont-email.me>, at 17:07:00 on Tue, 14 Dec
>>>>>> 2021, Recliner <recliner.usenet@gmail.com> remarked:
>>>>>
>>>>>>> You can perfectly well view PDFs with no Adobe software installed.
>>>>>>
>>>>>> That's true, although the rail ticketing sites direct you very strongly
>>>>>> towards using Adobe. Maybe that's something else they ought to review?
>>>>>
>>>>> I think the point is that Acrobat is both cross-platform and a dedicated
>>>>> PDF viewer, whereas other apps may only work for one or the other
>>>>> platform and other cross-platform apps, while they may do PDF as a
>>>>> secondary function, are not aimed specifically at that use case. So
>>>>> suggesting that customers install Acrobat is probably the simplest way
>>>>> of helping those who do not already have a PDF viewer installed, because
>>>>> the TOCs know it will work for everybody.
>>>>>
>>>>
>>>> Adobe owns the PDF format, so there may be some requirement to mention
>>>> it when recommending PDF viewers.
>>>>
>>>> In any case, with large, complex PDFs (not rail tickets), not all
>>>> viewers produce the same rendering, and it would normally be the case
>>>> that the Adobe rendering is most likely to be correct (if only because
>>>> it's the one rendering that's very likely to have been tested by the
>>>> author of the PDF).
>>>>
>>>> But I wouldn't have expected an experienced PC user (where the same
>>>> considerations apply) like Roland to have been tripped up so badly on
>>>> this trivial issue that doesn't seem to phase even novice mobile phone
>>>> users. It's as if Roland has only just acquired his very first Android
>>>> phone and is baffled by all the standard stuff that others take for
>>>> granted.
>>>
>>> An almost Norman-esque false premise there. My objection to PDFs is the
>>> way that it turns the delivery of tickets into a multi-phase process
>>> (which have several stages where extra glitches might, and indeed do,
>>> occur). Rather than simply using the 21st Century technology available
>>> within the mobile phone platform, to push them into the app's wallet.
>>>
>>> The secondary issue (which we should try to avoid hi-jacking the more
>>> fundamental proposition) is that the user might have to specially
>>> download and install (and possibly sign into) a PDF viewer.
>> It’s already been pointed out to you that the apps accept tickets
>>to their
>> in built wallet. PDF is an alternate means of delivery. Choice is a good
>> thing. If I were going on a long or expensive journey I’d print off the pdf
>> at home as a backup. My one real objection to phone based ticketing is that
>> they consider you to have no ticket if your phone fails. They make no
>> effort or provision to look things up on the back end, unlike an airline
>> (probably excepting Ryanair) who will find your booking if you wave your
>> passport at the desk. Even something like a nominal £1 fee to stop everyone
>> winding up the ticket inspector with spurious claims of phone non
>> functionality would be a step forwards.
>>
>Now that most (but not quite all) trains have USB charge points I
>suggest the time has come to make the flat battery rule only apply when
>there are operative charge points.
>
>XC Class 170s and the GWR HSTs are the only consists I know of without
>USB charge points.

While I haven't be "getting out" much recently because of the pandemic,
I'm sure there were many trains which just had 13A sockets (not USB
points).
--
Roland Perry

In message <spcb33$pl1$1@dont-email.me>, at 09:04:35 on Wed, 15 Dec
2021, Tweed <usenet.tweed@gmail.com> remarked:
>Tweed <usenet.tweed@gmail.com> wrote:
>> Roland Perry <roland@perry.co.uk> wrote:
>>> In message <spc5sf$sbe$1@dont-email.me>, at 07:35:43 on Wed, 15 Dec
>>> 2021, Tweed <usenet.tweed@gmail.com> remarked:
>>>> Roland Perry <roland@perry.co.uk> wrote:
>>>>> In message <c63irgdtobo6i0690q7rs3h8mjrog2arbf@4ax.com>, at 21:35:13 on
>>>>> Tue, 14 Dec 2021, Mark Goodge <usenet@listmail.good-stuff.co.uk>
>>>>> remarked:
>>>>>> On Tue, 14 Dec 2021 21:15:49 +0000, Recliner <recliner.usenet@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On Tue, 14 Dec 2021 19:24:03 +0000, Mark Goodge
>>>>>>> <usenet@listmail.good-stuff.co.uk> wrote:
>>>>>>>
>>>>>>>> On Tue, 14 Dec 2021 17:40:47 +0000, Roland Perry <roland@perry.co.uk>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> In message <spaivj$1j6$3@dont-email.me>, at 17:07:00 on Tue, 14 Dec
>>>>>>>>> 2021, Recliner <recliner.usenet@gmail.com> remarked:
>>>>>>>>
>>>>>>>>>> You can perfectly well view PDFs with no Adobe software installed.
>>>>>>>>>
>>>>>>>>> That's true, although the rail ticketing sites direct you very
>>>>>>>>>strongly
>>>>>>>>> towards using Adobe. Maybe that's something else they ought to review?
>>>>>>>>
>>>>>>>> I think the point is that Acrobat is both cross-platform and a
>>>>>>>>dedicated
>>>>>>>> PDF viewer, whereas other apps may only work for one or the other
>>>>>>>> platform and other cross-platform apps, while they may do PDF as a
>>>>>>>> secondary function, are not aimed specifically at that use case. So
>>>>>>>> suggesting that customers install Acrobat is probably the simplest way
>>>>>>>> of helping those who do not already have a PDF viewer
>>>>>>>>installed, because
>>>>>>>> the TOCs know it will work for everybody.
>>>>>>>>
>>>>>>>
>>>>>>> Adobe owns the PDF format, so there may be some requirement to
>>>>>>>mention it
>>>>>>> when recommending PDF viewers.
>>>>>>
>>>>>> Not any more, they don't. They did develop it, but it's been an Open ISO
>>>>>> Standard since 2008.
>>>>>>
>>>>>>> In any case, with large, complex PDFs (not rail tickets), not all
>>>>>>> viewers produce the same rendering, and it would normally be the case
>>>>>>> that the Adobe rendering is most likely to be correct (if only because
>>>>>>> it's the one rendering that's very likely to have been tested by the
>>>>>>> author of the PDF).
>>>>>>
>>>>>> The whole point of PDF is that it will look identical on any device when
>>>>>> rendered by any software. There are some advanced features, such as
>>>>>> editable forms and a document tree, which not all read-only viewers
>>>>>> support. But any given page of a PDF document will render identically in
>>>>>> any standards-compliant software.
>>>>>>
>>>>>> In any case, the key part of an e-ticket is the QR code, which is simply
>>>>>> an embedded image.
>>>>>
>>>>> That's interesting. Are you saying that the QR code is a jpeg embedded
>>>>> in the PDF? (There's still the open question why an e-ticket needs so
>>>>> much information, when an 8-digit code should be sufficient to index the
>>>>> database).
>>>>>
>>>> Because you might want to encode information for offline use. Consider an
>>>> on train ticket inspector.
>>>
>>>> Their machine is never going to be 100% online due to the nature of land to
>>>> train communications.
>>>
>>> Fair enough, so an e-ticket by design, but a bearer bond in practice
>>> when the comms are flaky.
>>>
>>
>> There’s no shades of grey in your world are there? That’s at the
>>root of a lot of the issues on here.
>
>Another analogy might be a QR encoded airline ticket. That’s a token back
>to the airline’s booking engine. But I bet when you use it to enter the
>security lane at the airport it doesn’t trigger a real time interrogation
>of that database. More likely it looks for an encoded date and the name of
>the starting airport, and checks that the pass hasn’t been used on that
>portal before to prevent pass back.

In that case I'd suggest it was more akin to an m-boarding_pass (and not
really a ticket at all).

Even when fully e-ticketed (as most airlines have for decades) you still
tended to get paper boarding passes[1], which are required by the
security lane as well as the door to the plane.

[1] I used to print off the barcoded A4 sheets from BMIbaby which got
rejected about half the time at the security lane, so had to go
queue at the ticket desk to get a replacement.
--
Roland Perry

"Roland Perry" <roland@perry.co.uk> wrote in message
news:KDnlDOXuNbuhFAuX@perry.uk...
>>>>>> In any case, the key part of an e-ticket is the QR code, which is
>>>>>> simply
>>>>>> an embedded image.
>>>>>
>>>>> That's interesting. Are you saying that the QR code is a jpeg embedded
>>>>> in the PDF?

Yes I'm surprised at this. I'd expect a QR or bar code to be a vector image
(eg SVG) that was capable of being rescaled by the browser/PDF reader
without scaling or lossy-compression artefacts.

"Roland Perry" <roland@perry.co.uk> wrote in message
news:1AQazrZybbuhFAoY@perry.uk...

> While I haven't be "getting out" much recently because of the pandemic,
> I'm sure there were many trains which just had 13A sockets (not USB
> points).

If I needed to use my phone or other USB-charged device on a train for a
long time (or to leave enough battery for the rest of the day) I'd always
take my mains charger in case there wasn't a USB charging socket. Also,
charging by mains, using a fast-rate charger (device and USB charger
negotiate a higher voltage and/or higher current) is quicker than charging
by non-enhanced USB: that may be relevant for a shorter journey where there
isn't much charging time on the train.

Actually, if I really need to have phone power (and power for other USB
devices) all day when I'm on the move, I take a USB battery, but that is
fairly heavy, and a lead disappearing into a coat pocket or a bag might
attract the attention of anti-terrorist people :-(

Roland Perry <roland@perry.co.uk> wrote:
> In message <spcb33$pl1$1@dont-email.me>, at 09:04:35 on Wed, 15 Dec
> 2021, Tweed <usenet.tweed@gmail.com> remarked:
>> Tweed <usenet.tweed@gmail.com> wrote:
>>> Roland Perry <roland@perry.co.uk> wrote:
>>>> In message <spc5sf$sbe$1@dont-email.me>, at 07:35:43 on Wed, 15 Dec
>>>> 2021, Tweed <usenet.tweed@gmail.com> remarked:
>>>>> Roland Perry <roland@perry.co.uk> wrote:
>>>>>> In message <c63irgdtobo6i0690q7rs3h8mjrog2arbf@4ax.com>, at 21:35:13 on
>>>>>> Tue, 14 Dec 2021, Mark Goodge <usenet@listmail.good-stuff.co.uk>
>>>>>> remarked:
>>>>>>> On Tue, 14 Dec 2021 21:15:49 +0000, Recliner <recliner.usenet@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Tue, 14 Dec 2021 19:24:03 +0000, Mark Goodge
>>>>>>>> <usenet@listmail.good-stuff.co.uk> wrote:
>>>>>>>>
>>>>>>>>> On Tue, 14 Dec 2021 17:40:47 +0000, Roland Perry <roland@perry.co.uk>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> In message <spaivj$1j6$3@dont-email.me>, at 17:07:00 on Tue, 14 Dec
>>>>>>>>>> 2021, Recliner <recliner.usenet@gmail.com> remarked:
>>>>>>>>>
>>>>>>>>>>> You can perfectly well view PDFs with no Adobe software installed.
>>>>>>>>>>
>>>>>>>>>> That's true, although the rail ticketing sites direct you very
>>>>>>>>>> strongly
>>>>>>>>>> towards using Adobe. Maybe that's something else they ought to review?
>>>>>>>>>
>>>>>>>>> I think the point is that Acrobat is both cross-platform and a
>>>>>>>>> dedicated
>>>>>>>>> PDF viewer, whereas other apps may only work for one or the other
>>>>>>>>> platform and other cross-platform apps, while they may do PDF as a
>>>>>>>>> secondary function, are not aimed specifically at that use case. So
>>>>>>>>> suggesting that customers install Acrobat is probably the simplest way
>>>>>>>>> of helping those who do not already have a PDF viewer
>>>>>>>>> installed, because
>>>>>>>>> the TOCs know it will work for everybody.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Adobe owns the PDF format, so there may be some requirement to
>>>>>>>> mention it
>>>>>>>> when recommending PDF viewers.
>>>>>>>
>>>>>>> Not any more, they don't. They did develop it, but it's been an Open ISO
>>>>>>> Standard since 2008.
>>>>>>>
>>>>>>>> In any case, with large, complex PDFs (not rail tickets), not all
>>>>>>>> viewers produce the same rendering, and it would normally be the case
>>>>>>>> that the Adobe rendering is most likely to be correct (if only because
>>>>>>>> it's the one rendering that's very likely to have been tested by the
>>>>>>>> author of the PDF).
>>>>>>>
>>>>>>> The whole point of PDF is that it will look identical on any device when
>>>>>>> rendered by any software. There are some advanced features, such as
>>>>>>> editable forms and a document tree, which not all read-only viewers
>>>>>>> support. But any given page of a PDF document will render identically in
>>>>>>> any standards-compliant software.
>>>>>>>
>>>>>>> In any case, the key part of an e-ticket is the QR code, which is simply
>>>>>>> an embedded image.
>>>>>>
>>>>>> That's interesting. Are you saying that the QR code is a jpeg embedded
>>>>>> in the PDF? (There's still the open question why an e-ticket needs so
>>>>>> much information, when an 8-digit code should be sufficient to index the
>>>>>> database).
>>>>>>
>>>>> Because you might want to encode information for offline use. Consider an
>>>>> on train ticket inspector.
>>>>
>>>>> Their machine is never going to be 100% online due to the nature of land to
>>>>> train communications.
>>>>
>>>> Fair enough, so an e-ticket by design, but a bearer bond in practice
>>>> when the comms are flaky.
>>>>
>>>
>>> There’s no shades of grey in your world are there? That’s at the
>>> root of a lot of the issues on here.
>>
>> Another analogy might be a QR encoded airline ticket. That’s a token back
>> to the airline’s booking engine. But I bet when you use it to enter the
>> security lane at the airport it doesn’t trigger a real time interrogation
>> of that database. More likely it looks for an encoded date and the name of
>> the starting airport, and checks that the pass hasn’t been used on that
>> portal before to prevent pass back.
>
> In that case I'd suggest it was more akin to an m-boarding_pass (and not
> really a ticket at all).
>
> Even when fully e-ticketed (as most airlines have for decades) you still
> tended to get paper boarding passes[1], which are required by the
> security lane as well as the door to the plane.

No, boarding cards on phones are normally perfectly acceptable, with no
printed version required.

>
> [1] I used to print off the barcoded A4 sheets from BMIbaby which got
> rejected about half the time at the security lane, so had to go
> queue at the ticket desk to get a replacement.

That was many years ago. Tech has moved on since your flying days.

On Wed, 15 Dec 2021 06:45:56 +0000, Roland Perry <roland@perry.co.uk>
wrote:

>In message <c63irgdtobo6i0690q7rs3h8mjrog2arbf@4ax.com>, at 21:35:13 on
>Tue, 14 Dec 2021, Mark Goodge <usenet@listmail.good-stuff.co.uk>
>remarked:

>>In any case, the key part of an e-ticket is the QR code, which is simply
>>an embedded image.
>
>That's interesting. Are you saying that the QR code is a jpeg embedded
>in the PDF? (There's still the open question why an e-ticket needs so
>much information, when an 8-digit code should be sufficient to index the
>database).

Well, I don't know for certain, since I don't happen to have a railway
e-ticket available to inspect. But it is certainly true for e-tickets
from other sources that I do have. If I open them with a PDF editor,
then the QR code is an image which can be extracted separately.

Although, oddly enough, a standard 1-dimensional[1] barcode isn't
usually an image, it's a rendered series of lines of different
thicknesses. If you copy and paste it into a text editor, what you
actually get is just a series of digits, which happens to be the barcode
(it's the same as the number printed below the barcode). From a
technical point of view, the lines in a standard barcode are just a
special font (a bit like dingbats) which renders digits as lines.

>(On a related note, I've always wondered why my scanner has options to
> produce jpeg or pdf files, when the latter appear to be simply a pdf
> wrapper around an otherwise identical jpeg. Not sure what extra it
> brings to the party, other than to satisfy organisations who might
> demand a pdf format for some internal reason of their own).

Wrapping it in a PDF will give you a document that is a fixed physical
size in mm or inches (eg A4 or Letter), which is useful if you plan to
print the scan. A jpg or tiff will have a digital size in pixels, which
is more useful if you plan to display it on a screen (or embed it onto a
different document), but makes for more work if you want to print it as
you may need to manually scale it to fit the page.

[1] I don't know why people call a QR code a "3D barcode", because it's
only two dimensions (horizontal and vertical, as opposed to a standard
barcode which is just horizontal). A 3D barcode would need to be a solid
object that does actually have three dimensions.

Mark

On 15/12/2021 09:35, Roland Perry wrote:
> In message <spcbvm$v0u$1@dont-email.me>, at 09:19:49 on Wed, 15 Dec
> 2021, martin.coffee@round-midnight.org.uk remarked:
>> On 15/12/2021 07:17, Tweed wrote:
>>> Roland Perry <roland@perry.co.uk> wrote:
>>>> In message <t02irgtihactd9p5p7bktssvd1cqbf203u@4ax.com>, at 21:15:49 on
>>>> Tue, 14 Dec 2021, Recliner <recliner.usenet@gmail.com> remarked:
>>>>> On Tue, 14 Dec 2021 19:24:03 +0000, Mark Goodge
>>>>> <usenet@listmail.good-stuff.co.uk> wrote:
>>>>>
>>>>>> On Tue, 14 Dec 2021 17:40:47 +0000, Roland Perry <roland@perry.co.uk>
>>>>>> wrote:
>>>>>>
>>>>>>> In message <spaivj$1j6$3@dont-email.me>, at 17:07:00 on Tue, 14 Dec
>>>>>>> 2021, Recliner <recliner.usenet@gmail.com> remarked:
>>>>>>
>>>>>>>> You can perfectly well view PDFs with no Adobe software installed.
>>>>>>>
>>>>>>> That's true, although the rail ticketing sites direct you very
>>>>>>> strongly
>>>>>>> towards using Adobe. Maybe that's something else they ought to
>>>>>>> review?
>>>>>>
>>>>>> I think the point is that Acrobat is both cross-platform and a
>>>>>> dedicated
>>>>>> PDF viewer, whereas other apps may only work for one or the other
>>>>>> platform and other cross-platform apps, while they may do PDF as a
>>>>>> secondary function, are not aimed specifically at that use case. So
>>>>>> suggesting that customers install Acrobat is probably the simplest
>>>>>> way
>>>>>> of helping those who do not already have a PDF viewer installed,
>>>>>> because
>>>>>> the TOCs know it will work for everybody.
>>>>>>
>>>>>
>>>>> Adobe owns the PDF format, so there may be some requirement to mention
>>>>> it when recommending PDF viewers.
>>>>>
>>>>> In any case, with large, complex PDFs (not rail tickets), not all
>>>>> viewers produce the same rendering, and it would normally be the case
>>>>> that the Adobe rendering is most likely to be correct (if only because
>>>>> it's the one rendering that's very likely to have been tested by the
>>>>> author of the PDF).
>>>>>
>>>>> But I wouldn't have expected an experienced PC user (where the same
>>>>> considerations apply) like Roland to have been tripped up so badly on
>>>>> this trivial issue that doesn't seem to phase even novice mobile phone
>>>>> users. It's as if Roland has only just acquired his very first Android
>>>>> phone and is baffled by all the standard stuff that others take for
>>>>> granted.
>>>>
>>>> An almost Norman-esque false premise there. My objection to PDFs is the
>>>> way that it turns the delivery of tickets into a multi-phase process
>>>> (which have several stages where extra glitches might, and indeed do,
>>>> occur). Rather than simply using the 21st Century technology available
>>>> within the mobile phone platform, to push them into the app's wallet.
>>>>
>>>> The secondary issue (which we should try to avoid hi-jacking the more
>>>> fundamental proposition) is that the user might have to specially
>>>> download and install (and possibly sign into) a PDF viewer.
>>>  It’s already been pointed out to you that the apps accept tickets to
>>> their
>>> in built wallet. PDF is an alternate means of delivery. Choice is a good
>>> thing. If I were going on a long or expensive journey I’d print off
>>> the pdf
>>> at home as a backup. My one real objection to phone based ticketing
>>> is that
>>> they consider you to have no ticket if your phone fails. They make no
>>> effort or provision to look things up on the back end, unlike an airline
>>> (probably excepting Ryanair) who will find your booking if you wave your
>>> passport at the desk. Even something like a nominal £1 fee to stop
>>> everyone
>>> winding up the ticket inspector with spurious claims of phone non
>>> functionality would be a step forwards.
>>>
>> Now that most (but not quite all) trains have USB charge points I
>> suggest the time has come to make the flat battery rule only apply
>> when there are operative charge points.
>>
>> XC Class 170s and the GWR HSTs are the only consists I know of without
>> USB charge points.
>
> While I haven't be "getting out" much recently because of the pandemic,
> I'm sure there were many trains which just had 13A sockets (not USB
> points).

Some consists do have 13A sockets only but I've come to the conclusion
that it's unreasonable to expect travellers to carry the adapter. Some
13A sockets are installed that some adapters cannot be inserted due to
obstructions.

NY <me@privacy.invalid> wrote:
> "Roland Perry" <roland@perry.co.uk> wrote in message
> news:KDnlDOXuNbuhFAuX@perry.uk...
>>>>>>> In any case, the key part of an e-ticket is the QR code, which is
>>>>>>> simply
>>>>>>> an embedded image.
>>>>>>
>>>>>> That's interesting. Are you saying that the QR code is a jpeg embedded
>>>>>> in the PDF?
>
> Yes I'm surprised at this. I'd expect a QR or bar code to be a vector image
> (eg SVG) that was capable of being rescaled by the browser/PDF reader
> without scaling or lossy-compression artefacts.

Yes, I'm sure at least some are, maybe most. I don't know if there's a
general rule for embedded QR codes? In any case, I really don't think
they'd be JPEGs.

The NHS vaccination QR codes do seem to be vector diagrams.

On Tue, 14 Dec 2021 11:16:11 +0000, Roland Perry <roland@perry.co.uk>
wrote:

>In message <jl5frg91mcaoougmr7qqf5f7tps52pg4t1@4ax.com>, at 18:57:24 on
>Mon, 13 Dec 2021, Ken <ken@birchanger.com> remarked:
>>On Mon, 13 Dec 2021 15:45:47 +0000, Roland Perry <roland@perry.co.uk>
>>wrote:
>>
>>>In message <sov5ho$27d$1@dont-email.me>, at 09:10:16 on Fri, 10 Dec
>>>2021, Tweed <usenet.tweed@gmail.com> remarked:
>>>>Graeme Wall <rail@greywall.demon.co.uk> wrote:
>>>>> On 09/12/2021 19:21, Roland Perry wrote:
>>>>>> In message <soo710$nau$1@dont-email.me>, at 17:52:32 on Tue, 7 Dec 2021,
>>>>>> Graeme Wall <rail@greywall.demon.co.uk> remarked:
>>>>>>
>>>>>>>>  If rail tickets were the only ecommerce product I ever bought, it
>>>>>>>> might,  just, be acceptable. But given that I buy from perhaps a
>>>>>>>> hundred, it's a  bit rich for whatever ATOC/Fat-Controller is called
>>>>>>>> this week to expect  me to bend over backwards for *their* convenience.
>>>>>>
>>>>>>>>  Far better, if we got back to the hear of this thread, they could be
>>>>>>>> bothered to keep their ticket machines operational, or provide PERTIS
>>>>>>>> machines, so passengers weren't forced to buy at the last minute
>>>>>>>> using their mobile, stood in the rain in the station car park, on
>>>>>>>> pain of a £100 fine.
>>>>>>>
>>>>>>> You need to get yourself organised, oh, and an umbrella. Personally if
>>>>>>> it is pouring with rail I'd do the on-line ordering before I got out
>>>>>>> of the car.
>>>>>>
>>>>>> But I don't know the TVM is broken until I get to it.
>>>>>
>>>>> Doesn't stop you going back to the car to get out f the rain or even
>>>>> sheltering under the station canopy while you order the ticket. No need
>>>>> to stand in the rain.
>>>>
>>>>The real point is that once you can cope with buying electronic tickets,
>>>>which seems to be Roland’s problem, you don’t need to worry about the
>>>>existence of a TVM, rain or no rain.
>>>
>>>The problem is the patchy nature of e-ticketing.
>>>
>>>>So far his arguments have been that he doesn’t like the apps (excuses
>>>>various), so folk have suggested he uses the emailed pdf, which then
>>>>generates a long list of spurious reasons why that’s not workable either.
>>>
>>>The reasons aren't spurious, and only arise because the e-ticketing
>>>platform is unable (by design) to deliver the tickets to my phone by a
>>>less last-century method.
>>>
>>>Or as I've found out the last couple of days, unable to deliver them at
>>>all. ["We've emailed you the PDF" - panto 'oh no you haven't']
>>
>>It sounds very much to me as if you've managed to log in to the app
>>using a different email address to the one you used to buy the tickets
>>(you did create an account rather than buy as a guest, I hope?).
>
>I haven't made that rookie mistake! And it's something I specifically
>double-checked before buying my tickets a few days ago.
>
>And of course that wouldn't explain the lack-of-arrival of the PDF (when
>I did get the order confirmation) for the first one.

True, but there does seem to be something amiss with your account.
You've extrapolated from this to claim that GA tickets don't do what I
have told you they certainly do do (arrive as a sort of hybrid
eTicket/mTicket, in your terms).

I never got a fix for my inability to use the app earlier this year;
it took a phone reset to resolve. But I didn't come to the conclusion
that the Android version of the app was universally broken.

I belive you that GA ticketing doesn't work for you. I'd be grateful
if you'd accept my word that it works in at least one case.

On Tue, 14 Dec 2021 11:10:14 +0000, Roland Perry <roland@perry.co.uk>
wrote:

>In message <3f59rgl8a60k6mpfdi87j8tf74nt1d273l@4ax.com>, at 12:14:58 on
>Sat, 11 Dec 2021, Ken <ken@birchanger.com> remarked:
>>On Fri, 10 Dec 2021 10:14:46 +0000, Roland Perry <roland@perry.co.uk>
>>wrote:
>>
>>>In message <3o26rgldmt59ln4p41vh2soqfl90tg66k2@4ax.com>, at 08:11:29 on
>>>Fri, 10 Dec 2021, Ken <ken@birchanger.com> remarked:
>>>>On Thu, 9 Dec 2021 12:11:34 +0000, Roland Perry <roland@perry.co.uk>
>>>>wrote:
>>>>
>>>>>In message <57rrqgp2qelb6cfe8sjj3otebr3aeikhen@4ax.com>, at 11:00:46 on
>>>>>Mon, 6 Dec 2021, Ken <ken@birchanger.com> remarked:
>>>>>

>>>>
>>>>It worked for Bishop's Stortford to Liverpool St. just fine.
>>>
>>>I'll see what the website offers. But...
>>>
>>>>Note that in my earlier replies I never claimed you were offered the
>>>>option to have an mTicket. Just that if you select pdf you seem to get
>>>>a single ticket than can be used as a pdf (e.g. printed) and also
>>>>apears in 'My Tickets' on the GA app.
>>>
>>>...I wonder why they don't tell customers that might happen?
>>>
>>>That's a bit of a big mystery purchase to make, but I might have a poke
>>>around to see what cheaper fares there are. Mountfitchet to BS perhaps
>>>(I can get that down to £1.30 with a fictional Student Discount).
>>
>>That works. I bought one the other day (in the reverse direction) when
>>traffic in Stortford meant that my lift would be from Mountfitchet but
>>my rail ticket only went to BIS.
>
>Off we go then...
>
>And... "We'll email your tickets shortly to your registered address for
>you to show on your phone or print. You can also download your ticket to
>your iOS or Android app".
>
>But how? Not terribly useful that the link to their help pages:
>

It used to be that you went to Your Tickets in the app. All of your
journeys, new and old, were present. You could select a specific
ticket and download it. You then needed to activate it before travel.

Now they just appear (for me!). No need to download or to activate,
hence my earlier comment about an eTicket/mTicket hybrid.

> <https://greateranglia.custhelp.com/cgi-bin/greateranglia.cfg/php/endus
>er/std_alp.php>
>

Not very helpful, is it?

>...is broken. <sigh> and <sigh> again.

In message <spca9r$ktc$1@dont-email.me>, at 09:51:10 on Wed, 15 Dec
2021, Rolf Mantel <news@hartig-mantel.de> remarked:

>Am 15.12.2021 um 07:28 schrieb Roland Perry:

>> Or do we indeed have some hybrid animal, an e-ticket that's
>> redundantly offline coded with all the information we might expect
>> to find on an m-ticket?
>
>Would you count the DB IC/ICE online tickets to be M-tickets or E-Tickets?
>
>1) can be printed out and/or shown on the phone
>2) contains all information necessary both in barcode and in writing
>(can be validated offline)
>3) safety feautre: personalized, only valid with personal ID
>4) safety feature: online validation goes against database, offline
>validation marks tickets as used on database on synch

At the risk of being accused of inventing a new category, sounds like an
e-boarding_pass.

Being neither a completely free-standing ticket (a pastiche of a paper
one), nor the e-ticket which someone bought and remains an entry on a
database, the pointer to which later triggered issuing the
e-boarding_pass.
--
Roland Perry

In message <spcdpa$ac7$1@dont-email.me>, at 09:50:34 on Wed, 15 Dec
2021, Recliner <recliner.usenet@gmail.com> remarked:
>Roland Perry <roland@perry.co.uk> wrote:
>> In message <spcb33$pl1$1@dont-email.me>, at 09:04:35 on Wed, 15 Dec
>> 2021, Tweed <usenet.tweed@gmail.com> remarked:
>>> Tweed <usenet.tweed@gmail.com> wrote:
>>>> Roland Perry <roland@perry.co.uk> wrote:
>>>>> In message <spc5sf$sbe$1@dont-email.me>, at 07:35:43 on Wed, 15 Dec
>>>>> 2021, Tweed <usenet.tweed@gmail.com> remarked:
>>>>>> Roland Perry <roland@perry.co.uk> wrote:
>>>>>>> In message <c63irgdtobo6i0690q7rs3h8mjrog2arbf@4ax.com>, at 21:35:13 on
>>>>>>> Tue, 14 Dec 2021, Mark Goodge <usenet@listmail.good-stuff.co.uk>
>>>>>>> remarked:
>>>>>>>> On Tue, 14 Dec 2021 21:15:49 +0000, Recliner
>>>>>>>><recliner.usenet@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Tue, 14 Dec 2021 19:24:03 +0000, Mark Goodge
>>>>>>>>> <usenet@listmail.good-stuff.co.uk> wrote:
>>>>>>>>>
>>>>>>>>>> On Tue, 14 Dec 2021 17:40:47 +0000, Roland Perry <roland@perry.co.uk>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> In message <spaivj$1j6$3@dont-email.me>, at 17:07:00 on Tue, 14 Dec
>>>>>>>>>>> 2021, Recliner <recliner.usenet@gmail.com> remarked:
>>>>>>>>>>
>>>>>>>>>>>> You can perfectly well view PDFs with no Adobe software installed.
>>>>>>>>>>>
>>>>>>>>>>> That's true, although the rail ticketing sites direct you
>>>>>>>>>>> strongly towards using Adobe. Maybe that's something else
>>>>>>>>>>>they ought to review?
>>>>>>>>>>
>>>>>>>>>> I think the point is that Acrobat is both cross-platform and
>>>>>>>>>> dedicated PDF viewer, whereas other apps may only work for
>>>>>>>>>>one or the other platform and other cross-platform apps,
>>>>>>>>>>while they may do PDF as a secondary function, are not aimed
>>>>>>>>>>specifically at that use case. So suggesting that customers
>>>>>>>>>>install Acrobat is probably the simplest way of helping those
>>>>>>>>>>who do not already have a PDF viewer installed, because the TOCs know it will work for everybody.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Adobe owns the PDF format, so there may be some requirement to
>>>>>>>>>mention it when recommending PDF viewers.
>>>>>>>>
>>>>>>>> Not any more, they don't. They did develop it, but it's been an
>>>>>>>>Open ISO
>>>>>>>> Standard since 2008.
>>>>>>>>
>>>>>>>>> In any case, with large, complex PDFs (not rail tickets), not all
>>>>>>>>> viewers produce the same rendering, and it would normally be the case
>>>>>>>>> that the Adobe rendering is most likely to be correct (if only because
>>>>>>>>> it's the one rendering that's very likely to have been tested by the
>>>>>>>>> author of the PDF).
>>>>>>>>
>>>>>>>> The whole point of PDF is that it will look identical on any
>>>>>>>>device when rendered by any software. There are some advanced
>>>>>>>>features, such as editable forms and a document tree, which not
>>>>>>>> support. But any given page of a PDF document will render
>>>>>>>>identically in any standards-compliant software.
>>>>>>>>
>>>>>>>> In any case, the key part of an e-ticket is the QR code, which
>>>>>>>>is simply an embedded image.
>>>>>>>
>>>>>>> That's interesting. Are you saying that the QR code is a jpeg embedded
>>>>>>> in the PDF? (There's still the open question why an e-ticket needs so
>>>>>>> much information, when an 8-digit code should be sufficient to index the
>>>>>>> database).
>>>>>>>
>>>>>> Because you might want to encode information for offline use. Consider an
>>>>>> on train ticket inspector.
>>>>>
>>>>>> Their machine is never going to be 100% online due to the nature
>>>>>>of land to
>>>>>> train communications.
>>>>>
>>>>> Fair enough, so an e-ticket by design, but a bearer bond in practice
>>>>> when the comms are flaky.
>>>>>
>>>>
>>>> There’s no shades of grey in your world are there? That’s at the
>>>> root of a lot of the issues on here.
>>>
>>> Another analogy might be a QR encoded airline ticket. That’s a token back
>>> to the airline’s booking engine. But I bet when you use it to enter the
>>> security lane at the airport it doesn’t trigger a real time interrogation
>>> of that database. More likely it looks for an encoded date and the name of
>>> the starting airport, and checks that the pass hasn’t been used on that
>>> portal before to prevent pass back.
>>
>> In that case I'd suggest it was more akin to an m-boarding_pass (and not
>> really a ticket at all).
>>
>> Even when fully e-ticketed (as most airlines have for decades) you still
>> tended to get paper boarding passes[1], which are required by the
>> security lane as well as the door to the plane.
>
>No, boarding cards on phones are normally perfectly acceptable, with no
>printed version required.

All they are is an image on a phone, instead of an image on paper. The
underlying principles of showing someone an image remain the same.

What matters is, whether the person/machine looking at the image checks
it against the central database or not.

>> [1] I used to print off the barcoded A4 sheets from BMIbaby which got
>> rejected about half the time at the security lane, so had to go
>> queue at the ticket desk to get a replacement.
>
>That was many years ago. Tech has moved on since your flying days.

Do Easyjet no longer let you print off paper boarding passes?
--
Roland Perry

<martin.coffee@round-midnight.org.uk> wrote:
> On 15/12/2021 07:17, Tweed wrote:
>> Roland Perry <roland@perry.co.uk> wrote:
>>> In message <t02irgtihactd9p5p7bktssvd1cqbf203u@4ax.com>, at 21:15:49 on
>>> Tue, 14 Dec 2021, Recliner <recliner.usenet@gmail.com> remarked:
>>>> On Tue, 14 Dec 2021 19:24:03 +0000, Mark Goodge
>>>> <usenet@listmail.good-stuff.co.uk> wrote:
>>>>
>>>>> On Tue, 14 Dec 2021 17:40:47 +0000, Roland Perry <roland@perry.co.uk>
>>>>> wrote:
>>>>>
>>>>>> In message <spaivj$1j6$3@dont-email.me>, at 17:07:00 on Tue, 14 Dec
>>>>>> 2021, Recliner <recliner.usenet@gmail.com> remarked:
>>>>>
>>>>>>> You can perfectly well view PDFs with no Adobe software installed.
>>>>>>
>>>>>> That's true, although the rail ticketing sites direct you very strongly
>>>>>> towards using Adobe. Maybe that's something else they ought to review?
>>>>>
>>>>> I think the point is that Acrobat is both cross-platform and a dedicated
>>>>> PDF viewer, whereas other apps may only work for one or the other
>>>>> platform and other cross-platform apps, while they may do PDF as a
>>>>> secondary function, are not aimed specifically at that use case. So
>>>>> suggesting that customers install Acrobat is probably the simplest way
>>>>> of helping those who do not already have a PDF viewer installed, because
>>>>> the TOCs know it will work for everybody.
>>>>>
>>>>
>>>> Adobe owns the PDF format, so there may be some requirement to mention
>>>> it when recommending PDF viewers.
>>>>
>>>> In any case, with large, complex PDFs (not rail tickets), not all
>>>> viewers produce the same rendering, and it would normally be the case
>>>> that the Adobe rendering is most likely to be correct (if only because
>>>> it's the one rendering that's very likely to have been tested by the
>>>> author of the PDF).
>>>>
>>>> But I wouldn't have expected an experienced PC user (where the same
>>>> considerations apply) like Roland to have been tripped up so badly on
>>>> this trivial issue that doesn't seem to phase even novice mobile phone
>>>> users. It's as if Roland has only just acquired his very first Android
>>>> phone and is baffled by all the standard stuff that others take for
>>>> granted.
>>>
>>> An almost Norman-esque false premise there. My objection to PDFs is the
>>> way that it turns the delivery of tickets into a multi-phase process
>>> (which have several stages where extra glitches might, and indeed do,
>>> occur). Rather than simply using the 21st Century technology available
>>> within the mobile phone platform, to push them into the app's wallet.
>>>
>>> The secondary issue (which we should try to avoid hi-jacking the more
>>> fundamental proposition) is that the user might have to specially
>>> download and install (and possibly sign into) a PDF viewer.
>>
>> It’s already been pointed out to you that the apps accept tickets to their
>> in built wallet. PDF is an alternate means of delivery. Choice is a good
>> thing. If I were going on a long or expensive journey I’d print off the pdf
>> at home as a backup. My one real objection to phone based ticketing is that
>> they consider you to have no ticket if your phone fails. They make no
>> effort or provision to look things up on the back end, unlike an airline
>> (probably excepting Ryanair) who will find your booking if you wave your
>> passport at the desk. Even something like a nominal £1 fee to stop everyone
>> winding up the ticket inspector with spurious claims of phone non
>> functionality would be a step forwards.
>>
> Now that most (but not quite all) trains have USB charge points I
> suggest the time has come to make the flat battery rule only apply when
> there are operative charge points.
>
> XC Class 170s and the GWR HSTs are the only consists I know of without
> USB charge points.
>

Not much use if you don’t have a cable with you. That’s probably the case
for very many travellers. Phones also die, get their screens smashed and
endless other reasons why they suddenly become inoperative. Completely
invalidating a ticket and demanding a new one, probably at Anytime rates,
is unfair to someone who has purchased a phone based ticket in good faith,
especially when the railway does have the means of looking it up.

Roland Perry <roland@perry.co.uk> wrote:
> In message <spcdpa$ac7$1@dont-email.me>, at 09:50:34 on Wed, 15 Dec
> 2021, Recliner <recliner.usenet@gmail.com> remarked:
>> Roland Perry <roland@perry.co.uk> wrote:
>>> In message <spcb33$pl1$1@dont-email.me>, at 09:04:35 on Wed, 15 Dec
>>> 2021, Tweed <usenet.tweed@gmail.com> remarked:
>>>> Tweed <usenet.tweed@gmail.com> wrote:
>>>>> Roland Perry <roland@perry.co.uk> wrote:
>>>>>> In message <spc5sf$sbe$1@dont-email.me>, at 07:35:43 on Wed, 15 Dec
>>>>>> 2021, Tweed <usenet.tweed@gmail.com> remarked:
>>>>>>> Roland Perry <roland@perry.co.uk> wrote:
>>>>>>>> In message <c63irgdtobo6i0690q7rs3h8mjrog2arbf@4ax.com>, at 21:35:13 on
>>>>>>>> Tue, 14 Dec 2021, Mark Goodge <usenet@listmail.good-stuff.co.uk>
>>>>>>>> remarked:
>>>>>>>>> On Tue, 14 Dec 2021 21:15:49 +0000, Recliner
>>>>>>>>> <recliner.usenet@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Tue, 14 Dec 2021 19:24:03 +0000, Mark Goodge
>>>>>>>>>> <usenet@listmail.good-stuff.co.uk> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Tue, 14 Dec 2021 17:40:47 +0000, Roland Perry <roland@perry.co.uk>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> In message <spaivj$1j6$3@dont-email.me>, at 17:07:00 on Tue, 14 Dec
>>>>>>>>>>>> 2021, Recliner <recliner.usenet@gmail.com> remarked:
>>>>>>>>>>>
>>>>>>>>>>>>> You can perfectly well view PDFs with no Adobe software installed.
>>>>>>>>>>>>
>>>>>>>>>>>> That's true, although the rail ticketing sites direct you
>>>>>>>>>>>> strongly towards using Adobe. Maybe that's something else
>>>>>>>>>>>> they ought to review?
>>>>>>>>>>>
>>>>>>>>>>> I think the point is that Acrobat is both cross-platform and
>>>>>>>>>>> dedicated PDF viewer, whereas other apps may only work for
>>>>>>>>>>> one or the other platform and other cross-platform apps,
>>>>>>>>>>> while they may do PDF as a secondary function, are not aimed
>>>>>>>>>>> specifically at that use case. So suggesting that customers
>>>>>>>>>>> install Acrobat is probably the simplest way of helping those
>>>>>>>>>>> who do not already have a PDF viewer installed, because the
>>>>>>>>>>> TOCs know it will work for everybody.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Adobe owns the PDF format, so there may be some requirement to
>>>>>>>>>> mention it when recommending PDF viewers.
>>>>>>>>>
>>>>>>>>> Not any more, they don't. They did develop it, but it's been an
>>>>>>>>> Open ISO
>>>>>>>>> Standard since 2008.
>>>>>>>>>
>>>>>>>>>> In any case, with large, complex PDFs (not rail tickets), not all
>>>>>>>>>> viewers produce the same rendering, and it would normally be the case
>>>>>>>>>> that the Adobe rendering is most likely to be correct (if only because
>>>>>>>>>> it's the one rendering that's very likely to have been tested by the
>>>>>>>>>> author of the PDF).
>>>>>>>>>
>>>>>>>>> The whole point of PDF is that it will look identical on any
>>>>>>>>> device when rendered by any software. There are some advanced
>>>>>>>>> features, such as editable forms and a document tree, which not
>>>>>>>>> support. But any given page of a PDF document will render
>>>>>>>>> identically in any standards-compliant software.
>>>>>>>>>
>>>>>>>>> In any case, the key part of an e-ticket is the QR code, which
>>>>>>>>> is simply an embedded image.
>>>>>>>>
>>>>>>>> That's interesting. Are you saying that the QR code is a jpeg embedded
>>>>>>>> in the PDF? (There's still the open question why an e-ticket needs so
>>>>>>>> much information, when an 8-digit code should be sufficient to index the
>>>>>>>> database).
>>>>>>>>
>>>>>>> Because you might want to encode information for offline use. Consider an
>>>>>>> on train ticket inspector.
>>>>>>
>>>>>>> Their machine is never going to be 100% online due to the nature
>>>>>>> of land to
>>>>>>> train communications.
>>>>>>
>>>>>> Fair enough, so an e-ticket by design, but a bearer bond in practice
>>>>>> when the comms are flaky.
>>>>>>
>>>>>
>>>>> There’s no shades of grey in your world are there? That’s at the
>>>>> root of a lot of the issues on here.
>>>>
>>>> Another analogy might be a QR encoded airline ticket. That’s a token back
>>>> to the airline’s booking engine. But I bet when you use it to enter the
>>>> security lane at the airport it doesn’t trigger a real time interrogation
>>>> of that database. More likely it looks for an encoded date and the name of
>>>> the starting airport, and checks that the pass hasn’t been used on that
>>>> portal before to prevent pass back.
>>>
>>> In that case I'd suggest it was more akin to an m-boarding_pass (and not
>>> really a ticket at all).
>>>
>>> Even when fully e-ticketed (as most airlines have for decades) you still
>>> tended to get paper boarding passes[1], which are required by the
>>> security lane as well as the door to the plane.
>>
>> No, boarding cards on phones are normally perfectly acceptable, with no
>> printed version required.
>
> All they are is an image on a phone, instead of an image on paper. The
> underlying principles of showing someone an image remain the same.
>
> What matters is, whether the person/machine looking at the image checks
> it against the central database or not.
>
>>> [1] I used to print off the barcoded A4 sheets from BMIbaby which got
>>> rejected about half the time at the security lane, so had to go
>>> queue at the ticket desk to get a replacement.
>>
>> That was many years ago. Tech has moved on since your flying days.
>
> Do Easyjet no longer let you print off paper boarding passes?

Yes, of course you can.

Roland Perry <roland@perry.co.uk> wrote:
> In message <ul44rgh3pooqqimstcdg7bt0tv3npqfi12@4ax.com>, at 14:46:17 on
> Thu, 9 Dec 2021, Mark Goodge <usenet@listmail.good-stuff.co.uk>
> remarked:
>
>> Gmail (on my phone) and Apple Mail (on my iPad) work fine for me. Both
>> of them support all the email accounts that I use. Looking at Spark on
>> Google Play, I see that it, too, can connect to Gmail, Exchange and
>> IMAP, and can handle multiple email accounts on the same device. It has
>> a few features which Gmail and Apple Mail don't have (such as the
>> ability to schedule email to be sent in the future), but none of them
>> look like the killer feature that would persuade me to switch.
>
> A killer feature could be along the lines of "how can it show me a
> display with a hundred or so waiting emails to pick from, on such a
> small screen"?
>

Use the search function?

Anna Noyd-Dryver

Roland Perry <roland@perry.co.uk> wrote:
> In message <sosn20$qnk$1@dont-email.me>, at 10:50:40 on Thu, 9 Dec 2021,
> Sam Wilson <ukr@dummy.wislons.fastmail.co.uk> remarked:
>
>>>>> As I've posted in several replies today, the issue isn't with IMAP, it's
>>>>> with the sorting and storing of thousands of emails on a phone (however
>>>>> it was they arrived there).
>>>>
>>>> But they’re only cached on the phone. Your client doesn’t need to store
>>>> thousands of email on the phone.
>>>
>>> It needs to provide a view of thousands of emails, even if only an
>>> extract from the headers. [Re-downloading] the bodies if they aren't
>>> cached requires satisfactory connectivity.
>>
>> So do server-side filtering (or manual filtering at home if you managed to
>> buy the ticket before getting out of your car in the rainy-sodden car park)
>> to put your e-tickets into a single folder and then access only that folder
>> on your phone when you need to display the ticket. That way only the
>> ticket folder needs to be cached on the phone.
>
> You are failing to answer the question of why I should go to all that
> bother, for just one of a hundred suppliers of e-commerce facilities,
> who insists on using 1992 technology to deliver tickets, simply because
> they propose to fine me £100 when *their* TVM is broken.
>

Do they? Surely 'ticket office closed and TVM broken' means 'no ticket
purchasing opportunities available' and therefore purchasing on-board or at
destination without penalty?

> Tell you what, this is how it *should* work:
>
> First of all provide paper tickets for people who want them. Actually,
> there are stations on the line where paper tickets from a TVM are *all*
> you have, for car parking.
>
> But for travellers, write an app that they can call up just before the
> train is due (not least because if the train turns out to have been
> cancelled, they might want to make alternative arrangements rather than
> wait an hour for the next one). Refund the parking ticket - maybe.
>
> The app knows where they are, and what the traveller's favourite tickets
> are. Bring up a pick-list, but obviously with a "something else",
> leading to some queries, if they are being adventurous.
>
> Push the ticket to the phone, so that *all* they have to do is present
> their NFC to a validator or barrier.
>
> Note the time when they touched out at the other end (the app would have
> to be tickling the NFC in anticipation) and twice for the return trip.
> At the end of the day, work out what the most appropriate fare would be
> (anytime, off-peak, railcard validity etc) and charge that to the
> customer's credit card.
>
> Send a simple SMS to the phone to confirm, and an email for archive
> purposes.
>
> If you want to put a cherry on the cake, automatically work out any
> delay-repay that's due, based on the train they must have been aiming
> for when they boarded, and what time the trains actually ran.
>
> There's no new or exciting technology there, just bothering to give the
> customer a better experience.

That's basically what SBB EasyRide does, but ISTR you (and Martin?)
complaining that that wasn't suitable either…

Anna Noyd-Dryver

Roland Perry <roland@perry.co.uk> wrote:
> In message <soko3p$ccm$2@dont-email.me>, at 10:19:37 on Mon, 6 Dec 2021,
> Graeme Wall <rail@greywall.demon.co.uk> remarked:
>> On 06/12/2021 09:28, Roland Perry wrote:
>>> In message <sog0jr$k1t$1@dont-email.me>, at 15:14:03 on Sat, 4 Dec
>>> 2021, Tweed <usenet.tweed@gmail.com> remarked:
>>>
>>>> There’s also nothing to stop you having an entirely different email
>>>> account, with a separate inbox for tickets. Most email clients handle
>>>> multiple accounts.
>
>>> That's something which doesn't scale on phones. I've tried this,
>>> specifically the last time this subject cropped up. And beyond about a
>>> dozen it gets unmanageable.
>>
>> You don't need a dozen, just one for tickets.
>
> Of all the transactions I might want to do on a phone, what gives trains
> companies the right to make such unique demands. (btw, the "dozen" is
> the number of TOCs I might use).

I don't find the concept of 'email a pdf to be shown on my phone' to be in
any way unique to TOCs.

Anna Noyd-Dryver

In message <4rdjrg1gc6d7vqnfivl8cdj8mvrgn9ulgh@4ax.com>, at 09:50:30 on
Wed, 15 Dec 2021, Mark Goodge <usenet@listmail.good-stuff.co.uk>
remarked:
>On Wed, 15 Dec 2021 06:45:56 +0000, Roland Perry <roland@perry.co.uk>
>wrote:
>
>>In message <c63irgdtobo6i0690q7rs3h8mjrog2arbf@4ax.com>, at 21:35:13 on
>>Tue, 14 Dec 2021, Mark Goodge <usenet@listmail.good-stuff.co.uk>
>>remarked:
>
>>>In any case, the key part of an e-ticket is the QR code, which is simply
>>>an embedded image.
>>
>>That's interesting. Are you saying that the QR code is a jpeg embedded
>>in the PDF? (There's still the open question why an e-ticket needs so
>>much information, when an 8-digit code should be sufficient to index the
>>database).
>
>Well, I don't know for certain, since I don't happen to have a railway
>e-ticket available to inspect.

I could send you one, if you like. [And I have, don't use it all at
once, because it's out of date and needs a child railcard]

>But it is certainly true for e-tickets from other sources that I do
>have. If I open them with a PDF editor, then the QR code is an image
>which can be extracted separately.

>Although, oddly enough, a standard 1-dimensional[1] barcode isn't
>usually an image, it's a rendered series of lines of different
>thicknesses. If you copy and paste it into a text editor, what you
>actually get is just a series of digits, which happens to be the barcode
>(it's the same as the number printed below the barcode). From a
>technical point of view, the lines in a standard barcode are just a
>special font (a bit like dingbats) which renders digits as lines.
>
>>(On a related note, I've always wondered why my scanner has options to
>> produce jpeg or pdf files, when the latter appear to be simply a pdf
>> wrapper around an otherwise identical jpeg. Not sure what extra it
>> brings to the party, other than to satisfy organisations who might
>> demand a pdf format for some internal reason of their own).
>
>Wrapping it in a PDF will give you a document that is a fixed physical
>size in mm or inches (eg A4 or Letter), which is useful if you plan to
>print the scan. A jpg or tiff will have a digital size in pixels, which
>is more useful if you plan to display it on a screen (or embed it onto a
>different document), but makes for more work if you want to print it as
>you may need to manually scale it to fit the page.

I find that spending half a second ticking the "fit to page width" box
works just fine.

>[1] I don't know why people call a QR code a "3D barcode", because it's
>only two dimensions (horizontal and vertical, as opposed to a standard
>barcode which is just horizontal). A 3D barcode would need to be a solid
>object that does actually have three dimensions.
>
>Mark

--
Roland Perry

On 15/12/2021 10:18, Anna Noyd-Dryver wrote:
> Roland Perry <roland@perry.co.uk> wrote:
>> In message <sosn20$qnk$1@dont-email.me>, at 10:50:40 on Thu, 9 Dec 2021,
>> Sam Wilson <ukr@dummy.wislons.fastmail.co.uk> remarked:
>>
>>>>>> As I've posted in several replies today, the issue isn't with IMAP, it's
>>>>>> with the sorting and storing of thousands of emails on a phone (however
>>>>>> it was they arrived there).
>>>>>
>>>>> But they’re only cached on the phone. Your client doesn’t need to store
>>>>> thousands of email on the phone.
>>>>
>>>> It needs to provide a view of thousands of emails, even if only an
>>>> extract from the headers. [Re-downloading] the bodies if they aren't
>>>> cached requires satisfactory connectivity.
>>>
>>> So do server-side filtering (or manual filtering at home if you managed to
>>> buy the ticket before getting out of your car in the rainy-sodden car park)
>>> to put your e-tickets into a single folder and then access only that folder
>>> on your phone when you need to display the ticket. That way only the
>>> ticket folder needs to be cached on the phone.
>>
>> You are failing to answer the question of why I should go to all that
>> bother, for just one of a hundred suppliers of e-commerce facilities,
>> who insists on using 1992 technology to deliver tickets, simply because
>> they propose to fine me £100 when *their* TVM is broken.
>>
>
> Do they? Surely 'ticket office closed and TVM broken' means 'no ticket
> purchasing opportunities available' and therefore purchasing on-board or at
> destination without penalty?
>
>> Tell you what, this is how it *should* work:
>>
>> First of all provide paper tickets for people who want them. Actually,
>> there are stations on the line where paper tickets from a TVM are *all*
>> you have, for car parking.
>>
>> But for travellers, write an app that they can call up just before the
>> train is due (not least because if the train turns out to have been
>> cancelled, they might want to make alternative arrangements rather than
>> wait an hour for the next one). Refund the parking ticket - maybe.
>>
>> The app knows where they are, and what the traveller's favourite tickets
>> are. Bring up a pick-list, but obviously with a "something else",
>> leading to some queries, if they are being adventurous.
>>
>> Push the ticket to the phone, so that *all* they have to do is present
>> their NFC to a validator or barrier.
>>
>> Note the time when they touched out at the other end (the app would have
>> to be tickling the NFC in anticipation) and twice for the return trip.
>> At the end of the day, work out what the most appropriate fare would be
>> (anytime, off-peak, railcard validity etc) and charge that to the
>> customer's credit card.
>>
>> Send a simple SMS to the phone to confirm, and an email for archive
>> purposes.
>>
>> If you want to put a cherry on the cake, automatically work out any
>> delay-repay that's due, based on the train they must have been aiming
>> for when they boarded, and what time the trains actually ran.
>>
>> There's no new or exciting technology there, just bothering to give the
>> customer a better experience.
>
> That's basically what SBB EasyRide does, but ISTR you (and Martin?)
> complaining that that wasn't suitable either…

I'm happy with TfW's m-tickets using their website and app in
conjunction. I have their ITSO card all ready for when they implement
it for normal tickets.

What I am not happy about is using emailed PDFs on my phone. I could
configure my email provider's system to add an additional email address
on my phone and home computer but I have no immediate need or
inclination to spend the time and effort. What's the point when TfW's
m-tickets work seamlessly.

In message <spcfck$km2$1@dont-email.me>, at 10:17:56 on Wed, 15 Dec
2021, Recliner <recliner.usenet@gmail.com> remarked:

>>>> [1] I used to print off the barcoded A4 sheets from BMIbaby which got
>>>> rejected about half the time at the security lane, so had to go
>>>> queue at the ticket desk to get a replacement.
>>>
>>> That was many years ago. Tech has moved on since your flying days.
>>
>> Do Easyjet no longer let you print off paper boarding passes?
>
>Yes, of course you can.

It's not completely moved on, then.
--
Roland Perry