The PDF file format specification has 971 pages.
https://www.iso.org/standard/63534.html
PEP – An open source PDF editor for Mac
81–90 of 113 posts
Re: PEP – An open source PDF editor for Mac
#82Earlier quoted context omitted.
Their whole UI is written in ObjC, they've got two decades of Mac apps in ObjC, and they wrote a whole new language to interface cleanly with ObjC but with nicer semantics, so I'm guessing ObjC isn't going anywhere. But even if Apple does remove it, everything apart from the UI would still compile in GCC's ObjC compiler. The guts of this project is the PDF engine, not the UI, and that would still work. TeX is written…
More than just their UI, fundamental parts of Apple's OSes are written in ObjC, including very new components like ARKit, CoreML, and the Metal API. Apple continues to write tons of new Objective-C code every day. Of course Swift is making inroads inside Apple, but Objective-C has to be well supported for a very long time to come. I've been writing Objective-C for 15 years, and continue to do about 60-70% of my work…
What about Cocoa? You think it still makes sense to invest dev time in a Cocoa app?
Re: PEP – An open source PDF editor for Mac
#83I have a dream... that one day people will name their projects with names that don't exist on google yet. If you search for PEP now you'll find python enhancement proposals, and the "Philippine Entertainment Portal" and the stock code for PepsiCo.
I wish that once people do name their project, they would assign it a 128-bit random number in lower case hex, and include that number on any web page that they would like people searching for their project to find. That way once I know that say PEP the PDF editor exists and find its 128-bit number (let's say that is 379dd864b16eaca3ce94c15a6bdfcc73), at least I can subsequently toss a +379dd864b16eaca3ce94c15a6bdfcc…
I too dream of content addressable web.
Re: PEP – An open source PDF editor for Mac
#84Earlier quoted context omitted.
More than just their UI, fundamental parts of Apple's OSes are written in ObjC, including very new components like ARKit, CoreML, and the Metal API. Apple continues to write tons of new Objective-C code every day. Of course Swift is making inroads inside Apple, but Objective-C has to be well supported for a very long time to come. I've been writing Objective-C for 15 years, and continue to do about 60-70% of my work…
What about Cocoa? You think it still makes sense to invest dev time in a Cocoa app?
That's a little more ambiguous. Until very recently I was primarily a Cocoa developer (took a full time iOS dev job a few months ago), and it still makes up a significant portion of my side work, so I'm biased. But right now, the alternatives are SwiftUI and UIKit/Catalyst. SwiftUI nicely integrates with AppKit/Cocoa, but anyway, it's in pretty rough shape on the Mac at the moment (see https://news.ycombinator.com/item?id=24472063 for example). Catalyst is (IMO) basically garbage if your goal is to make a great Mac app. Its purpose is to allow easy porting from iOS to Mac, not to create truly good Mac apps.
Obviously, the presence of these two technologies, and Apple's pushing them is evidence that Cocoa may be on its way out, but it's not deprecated, and is still officially the recommended way to build true Mac apps. Undoubtedly it's SwiftUI (not Catalyst) that will eventually displace it, but especially on the Mac, SwiftUI is not really ready for production yet.
Re: PEP – An open source PDF editor for Mac
#85I have a dream... that one day people will name their projects with names that don't exist on google yet. If you search for PEP now you'll find python enhancement proposals, and the "Philippine Entertainment Portal" and the stock code for PepsiCo.
I have a dream that dang will automate flagging and removing the inevitable inane comments about name uniqueness every time someone posts a project on HN.
Re: PEP – An open source PDF editor for Mac
#86Earlier quoted context omitted.
What about Cocoa? You think it still makes sense to invest dev time in a Cocoa app?
That's a little more ambiguous. Until very recently I was primarily a Cocoa developer (took a full time iOS dev job a few months ago), and it still makes up a significant portion of my side work, so I'm biased. But right now, the alternatives are SwiftUI and UIKit/Catalyst. SwiftUI nicely integrates with AppKit/Cocoa, but anyway, it's in pretty rough shape on the Mac at the moment (see https://news.ycombinator.com/it…
I agree with all your points.
I considered getting into Cocoa dev but between the lack of resources and the probability that Apple will kill it in the not so distant future, it didn't make much sense.
Better wait a couple of years until the mud settles.
Re: PEP – An open source PDF editor for Mac
#87Earlier quoted context omitted.
A 256 bit number is 2^256 possible combinations. 8^256 is the same as (2^3)^256 (or 2^768)
Er yeah. Derp. 8 character ascii not 8 bit. It's early. That's 8 bits ^ 8. Or 256 ^ 8. and easily able to be represented searching online with 8 characters.
Don't get discouraged, but you might still have a bug or two to work out with your new and never-before-tried "256^8 and easily able to be represented searching online with 8 characters" design. For your beta test, here are some of the unique 8-char identifiers you might want to try searching for:
`unique `, ` unique `, ` unique`, `Unique `, `u^Hunique`, `un^Hnique`, `uniq^H^H^H^H`, ` . . . .`, `. . . . `, `uniqueESCESC`, `BELBELBELBELBELBELBELBEL`, ...
Re: PEP – An open source PDF editor for Mac
#88Earlier quoted context omitted.
> I wish that once people do name their project, they would assign it a 128-bit random number in lower case hex We already have something similar: URLs.
Except a URL only points to one resource. The idea here is that this identifier would exist on any resource related to PEP (maybe even in URLs).
>Except a URL only points to one resource
isn't that exactly what this is asking for though? A URL can by definition only point to one resource. So if you include that URL with every other reference to the project (in the app descriptions, blog posts about it, etc) then you always know you're talking about the same thing. It makes a lot more sense that any resource related to this PDF editor should include a link to "https://macpep.org" instead of including some random 128 character string. Any resource related to python peps should include a link to "https://www.python.org/dev/peps/" (which all PEPs do, by virtue of having a url that's a subdirectory of the PEP index URL)
Re: PEP – An open source PDF editor for Mac
#89Earlier quoted context omitted.
That's a little more ambiguous. Until very recently I was primarily a Cocoa developer (took a full time iOS dev job a few months ago), and it still makes up a significant portion of my side work, so I'm biased. But right now, the alternatives are SwiftUI and UIKit/Catalyst. SwiftUI nicely integrates with AppKit/Cocoa, but anyway, it's in pretty rough shape on the Mac at the moment (see https://news.ycombinator.com/it…
I agree with all your points. I considered getting into Cocoa dev but between the lack of resources and the probability that Apple will kill it in the not so distant future, it didn't make much sense. Better wait a couple of years until the mud settles.
I think that's eminently reasonable. As someone with 15 years experience doing Cocoa dev, the intention to be a Mac dev indefinitely, and hundreds of thousands of lines of existing Cocoa and Cocoa Touch code, it's just going to be a slow transition. But there's no pressing reason to just stop writing any new Cocoa code (I literally wrote some since my last comment :-P). If I were starting now, I'd probably focus on SwiftUI with the assumption that it will be the way to start most new projects within the next few years.
Re: PEP – An open source PDF editor for Mac
#90A GUI app for manually crafting PDFs is one thing, but a library instead would enable countless developers to create software capable of producing PDF deliverables as output, possibly improving the accessibility situation too. I would gladly sponsor the development of a reliable library that allows to programmatically produce compliant, accessible tagged PDFs with arbitrary layout[0], correctly printable and viewable…
Is it possible to use inkscape as a library? If not you can always use whatever library to produce an SVG and convert it to PDF. Or are there features in PDF that is impossible to produce using SVG?
Most features of PDF can't be produced using SVG. The visual elements are just the surface of what PDFs can do and are used for.