CMYK data describes which inks a printer should use to print a color.
If a screen should display a color that's supposed to look similar
to what the printer produces, it results in a color very different
to what Color::from_cmyk() produces. (It's also printer-dependent.)
There are many ICC profiles describing printing processes. It doesn't
matter too much which one we use -- most of them look somewhat
similar, and they all look dramatically better than Color::from_cmyk().
This patch adds a function to download a zip file that Adobe offers
on their web site. They even have a page for redistribution:
https://www.adobe.com/support/downloads/iccprofiles/icc_eula_win_dist.html
(That one leads to a broken download though, so this downloads the
end-user version.)
In case we have to move off this download at some point, there are also
a whole bunch of profiles at https://www.color.org/registry/index.xalter
that "may be used, embedded, exchanged, and shared without restriction".
The adobe zip contains a whole bunch of other useful and fun profiles,
so I went with it.
For now, this only unzips the USWebCoatedSWOP.icc file though, and
installs it in ${CMAKE_BINARY_DIR}/Root/res/icc/Adobe/CMYK/. In
Serenity builds, this will make it to /res/icc/Adobe/CMYK in the
disk image. And in lagom build, after #23016 this is the
lagom res staging directory that tools can install via
Core::ResourceImplementation. `pdf` and `MacPDF` already do that,
`TestPDF` now does it too.
The final piece is that LibPDF then loads the profile from there
and uses it for DeviceCMYK color conversions.
(Doing file access from the bowels of a library is a bit weird,
especially in a system that has sandboxing built in. But LibGfx does
that in FontDatabase too already, and LibPDF uses that, so it's not a
new problem.)
We currently bundle AK with LibCore on Lagom. This means that to use AK,
all libraries must also depend on LibCore. This will create circular
dependencies when we create LibURL, as LibURL will depend on LibUnicode,
which will depend on LibCore, which will depend on LibURL.
...and hook it up.
I opened MainMenu.xib in Xcode, added a new "Submenu Menu Item"
from the Library (cmd-shift-l), added a User Defined
"toggleShowClippingPaths:" action on First Responder and connected
the menu item's action to that action.
(I first tried duplicating the existing Window menu and editing that,
but the Window menu is marked as `systemMenu="window"` in the xib and
I couldn't find a way to undo that in Xcode. So the Debug menu first
acted as a second Window menu.)
I made "Debug" a toplevel menu to make it consistent with Ladybird.app
for now, but I'll probably make it a submenu of "View" in the future.
This commit un-deprecates DeprecatedString, and repurposes it as a byte
string.
As the null state has already been removed, there are no other
particularly hairy blockers in repurposing this type as a byte string
(what it _really_ is).
This commit is auto-generated:
$ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \
Meta Ports Ladybird Tests Kernel)
$ perl -pie 's/\bDeprecatedString\b/ByteString/g;
s/deprecated_string/byte_string/g' $xs
$ clang-format --style=file -i \
$(git diff --name-only | grep \.cpp\|\.h)
$ gn format $(git ls-files '*.gn' '*.gni')
Else, outline items that have newlines in them end up with a weird
vertical offset.
(This does affect the outline item's tooltip, which shows the whole
title. But not having a newline there seems alright, arguably
preferable.)
The title of an OutlineItem is already in UTF-8.
This is currently done in LibPDF's Parser::parse_string(). I think
that's not quite the right place (it shouldn't be done for all strings)
and not done quite right (text strings should convert from
PDFDocEncoding to UTF-8 unless prefixed by an UTF-8 BOM), but even if
that changes, I think we'll keep OutlineItem.title in UTF-8.
I would've expected that there's some way to have this work
automatically in an NSDocument-based application, but I haven't
found it yet. So manually implement the delegate for now.
When the outline has focus, arrow keys navigate the outline instead
of changing the current page.
Add opt-up and opt-down as a way to move by one page even when the
outline has focus. (This matches Preview.app.)
xib change: Added two menu Previous Page with key equivalent opt-up
and Next Page with key equivalent opt-down to Go menu and bound them to
goToPreviousPage: and goToNextPage: on First Responder.
When the outline has focus, the responder chain is outline ->
window, so also add the actions on the window controller, and
let that forward to the PDF view.
I broke this when moving from a xib file to creating the UI in code.
https://developer.apple.com/documentation/appkit/nsuserinterfaceitemidentification/1396829-identifier
says:
"Identifiers are used during window restoration operations to uniquely
identify the windows of the application. [...] If you create an item in
Interface Builder and do not set a value for this string, a unique value
is created for the item when the nib file is loaded. For
programmatically created views, you typically set this value after
creating the item but before adding it to a window."
Without this, encodeRestorableStateWithCoder: / restoreStateWithCoder:
in MacPDFView weren't getting called.
The documentation is very loud about cell-based things being
deprecated, but it's fairly hidden what to actually do to switch to
the non-deprecated way (implement a certain delegate method).
Session 120 from WWDC 2011 has some notes on this. Apple's official
site no longer seems to have that, but it's e.g. here:
https://docs.huihoo.com/apple/wwdc/2011/session_120__view_based_nstableview.pdf
Just setting headerView to nil removes the header, but also has
the effect of no longer drawing the outline view with a sidebar
background ¯\_(ツ)_/¯.
But also setting drawsBackground to NO on the scroll view restores
the sidebar look, so do that too.
With this, it is no longer necessar to explicitly set style.
The default NSTableViewStyleAutomatic now seems to resolve to
NSTableViewStyleSourceList, so stop explicitly setting it.
(This part has no behavior change.)
Clicking an item in the outline now opens that page.
This requires giving the outline view a delegate, which for some
reason also has th effect of indenting expandable items ¯\_(ツ)_/¯
The vertical alignment of text still looks off, though.
The outline has drawing artifacts, but it is somewhat functional:
You can click on disclosure triangles to open outline items, and
if the outline doesn't fit in the sidebar, it's scrollable.
The outline view has the correct sidebar look: gray with a slightly
transparent glass effect.
Clicking items doesn't have an effect yet.
This Just Works with NSToolbarSidebarTrackingSeparatorItemIdentifier,
as long as your window is has NSWindowStyleMaskFullSizeContentView
in its style mask. If it doesn't, things behave pretty weirdly and
at least in the docs I looked at, this requirement wasn't documented
at all :/
Anyways, switch MacPDFView to use safeAreaRect instead of bounds
now that we use NSWindowStyleMaskFullSizeContentView so that we
don't draw parts of the PDF under the title bar.
Also be careful to invalidate the PDF view if safeAreaRect changes,
so that the page is redrawn when toolbar visibility gets toggled.
- MacPDFWindowController is now the xib file's owner
- _pdfView moves over
- MacPDFWindowController is now the MacPDFViewDelegate and responsible
for updating the window's title
- Due to MacPDFWindowController now being the xib file's owner,
windowControllerDidLoadNib: is no longer called automatically,
so call a custom windowIsReady method manually instead
No behavior change.
I'd like to add a sidebar, and NSSplitViewItem apparently isn't
accessibly in .xib files without contortions. So I want to move
to creating the window in code, and this is a step towards that.
No behavior change.
The bots complain that `forward()` could be either from libc++'s
include/c++/v1/__utility/forward.h or from AK/StdLibExtras.h.
I don't see this locally, but Ladybird also defined AK_DONT_REPLACE_STD,
so let's see if this does the trick.
Use `Meta/serenity.sh build lagom MacPDF` to build, and either of
`open Build/lagom/bin/MacPDF.app` or
`Build/lagom/bin/MacPDF.app/Contents/MacOS/MacPDF` to run.
Xcode used to insert a bunch of things to Info.plist. Now it can
no longer do that, so manually put them there
1. main.m is now main.mm
2. MainMenu.xib is now no longer in a Base.lproj subfolder
3. Remove SerenityPDF.entitlements since it won't be used in our CMake
build
xib changes:
* Add a "Go" toplevel submenu
* Put a "Go to Page..." menu item in it
* Add showGoToPageDialog: to first responder
* Bind action of new menu item to that
The dialog is just a janky NSAlert for now.
This is a bit janky for several reasons:
* `initialize` is now no longer called on a bg thread
* sheet UI is janky both visually and from an implementation PoV
But hey, it works for now.
